the "`ods html5(id=vscode)`" generates error

[ebf0248]

Describe the bug I'm trying to introduce VSCode in my company environment. We work on GRID and the setup is:

• VSCode version 1.91.1,
• Extension 1.10.1,
• SAS 9.4M7,
• SAS Integration Technologies Client for Windows Release 9.50,
• Windows 10

I managed to connect SAS from VSCode using IOM type. I can execute code, run data and proc steps, macrolanguage etc., I can preview libraries, and data sets in them.

Problem pops up when I want to get html5 ods results.

When I have "SAS.results.html.enabled": false the "ods html5(id=vscode)" is not generated and everything works "fine" (except we don't have html).

When I set: "SAS.results.html.enabled": true (the default option) then it "blows up", the "ods html5(id=vscode)" generates very odd error:

1             %let workDir = %sysfunc(pathname(work));
NOTE: The current working directory is now
      "/saswork/SAS_work1128000984A5_***************.***.***.******.*o/SAS_work712E000984A5_***************.***.***.******.*o".
5             %let rc = %sysfunc(dlgcdir("&workDir"));
6             run;
3                                                                                                                        The SAS System                                                                                        Friday, July 26, 2024 11:53:00 AM
7          /** LOG_START_INDICATOR **/
8          title;footnote;ods _all_ close;
9          ods graphics on;
10         ods html5(id=vscode) path="/saswork/SAS_work1128000984A5_***************.***.***.******.*o/SAS_work712E000984A5_***************.***.***.******.*o2                                                          The SAS System
10       ! Friday, July 26, 2024 11:53:00 AM"  style=Ignite options(bitmap_mode='inline' svg_mode='inline') body="7602af8e-3b96-4330-b648-e9b4854d215c.htm";
NOTE: Writing HTML5(VSCODE) Body file: 7602af8e-3b96-4330-b648-e9b4854d215c.htm
ERROR: Physical file does not exist, /saswork/SAS_work1128000984A5_***************.***.***.******.*o/SAS_work712E000984A5_***************.***.***.******.*o2                                                          The SAS System
       Friday, July 26, 2024 11:53:00 AM/7602af8e-3b96-4330-b648-e9b4854d215c.htm.
ERROR: No body file. HTML5(VSCODE) output will not be created.
11         %let _SASPROGRAMFILE = %nrquote(%nrstr(d:\Users\*******\*****************\Desktop\VSCode_to_TAGG_IOM_test1.sas));
12         resetline;
1          data _null_;
2          run;

It looks like when the ODS in line 10 is generated the path= grabs not only WORK directory but also a line from SAS long new page line ("2 The SAS System Friday, July 26, 2024 11:53:00 AM", with all that spaces and text...) The file is looked at: /saswork/SAS_work1128000984A5_***************.***.***.******.*o/SAS_work712E000984A5_***************.***.***.******.*o2 The SAS System Friday, July 26, 2024 11:53:00 AM/7602af8e-3b96-4330-b648-e9b4854d215c.htm

Nottice that in the log between line 6 and 7 we can see the beginning of page 3. While the error seems to happen with page 2.

And then when SAS tries to write to that file it obviously doesn't exist...

I wonder if you could share how that part of code (ods html...) is generated?

I know SAS, in DMS end EG, is adding a special FF symbol at the beginning of every page:

Can this be somehow related ? I'm trying to figure out what may be the reason. On my private machine I could not reproduce the error (first I thought it may be WORK path length, but not) so I'm searching for other options, e.g. server setup/autoexecs, etc.

Do you have someone in the dev team to talk about it?

Additional context Screen from today VSCode execution

[clangsmith]

@scottdover, this one reminds me of #861 and #978, since the SASWORK path was munged in those as well. Are we still relying on parsing the log here in some way? If so, I worry that relying on parsing the log simply cannot be done in a robust way and that we may need to look at handling similar to the way EG does.

[scnwwu]

@scottdover, this one reminds me of #861 and #978, since the SASWORK path was munged in those as well. Are we still relying on parsing the log here in some way? If so, I worry that relying on parsing the log simply cannot be done in a robust way and that we may need to look at handling similar to the way EG does.

Discussed in #810

[ebf0248]

Thank you for the information! I'm waiting for the next release then.