%p (working directory specification) not recognized, Win 10 in a virtualized environment (solved)

bobmcconn · Jun 19, 2017#12017-06-19T22:13+00:00

I have had an UltraEdit tool that instructs UltraEdit version 18.10.0.1018 when I submit a job from within UltraEdit to write the log & list to the same directory in which the SAS code is saved. This weekend something switched with the system so that UltraEdit despite the tool configuration attempts to send the log to the Windows directory, which even if it worked isn't what one would want.

Any ideas or suggestions on how to fix this?

We have used UltraEdit on many different systems for 20 years and the current virtual machine set up is the only one in which this problem has shown up. %p (in the working directory) is ignored and SAS attempts to write the log and lst files to the C:\Windows directory for which we do not have permissions.

Windows 10 Enterprise but under a virtual environment VMware virtual platform. As always thanks.

Mofi · Jun 20, 2017#22017-06-20T05:11+00:00

I'm quite sure this issue is not caused by UltraEdit. I suppose that the *.sas file is opened using an UNC path. Windows kernel does not allow that an UNC path is used as current directory of a process. Windows sets %SystemRoot% as current directory when this is nevertheless tried.

I suggest to configure in UltraEdit the user tool with an empty field for the working directory property and use for the command line:

"Path to batch file\BatchFileName.bat" "%f"

And the batch file BatchFileName.bat in directory Path to batch file contains the lines:

Code: Select all

@echo off
if "%~1" == "" goto :EOF
pushd "%~dp1"
rem Command line to run tool with "%~nx1"
popd

This batch file first checks if it is called with 1 argument which must be the *.sas file name with extension and with full path. The batch file is immediately exited when batch file is executed without an argument or with just "" as first argument.

The third command line sets the directory of the file as current directory after pushing the current directory on stack. With command extensions enabled as by default on Windows the command pushd automatically assigns next free drive letter to an UNC path if the specified path is an UNC path before it makes now instead of \\server\share\directory\ the directory with the drive letter the current working directory, i.e. X:\ with X being next free drive letter. For paths starting with a drive letter the current working directory is simply switched to specified path.

Now the current directory is the directory of the *.sas file and the command(s) can be executed using "%~nx1" for referencing the *.sas file with just file name and extension without path as the file is in current directory.

With last command line the previous current directory pushed before on stack is restored and popd removes also the temporary assignment of a drive letter to the UNC path if that was done before by command pushd because of path was an UNC path.

bobmcconn · Jun 20, 2017#32017-06-20T16:36+00:00

Thanks Mofi.

I suspected it was a UNC issue. But why it suddenly manifested itself after 4 months was a mystery to me!

Your solution worked a charm. I did need to stick the %p in the path, but that was a bit of trivial trial and error.
More than one person is going to be pleased to have a solution.

We have been mystified because tho we supposedly all have the same VMware virtual machine set up, how UltraEdit commands worked varied from person to person.

My "old" "path to SAS" %f with %p in the directory worked till this weekend, though I'd get a complaint about being "unable to write" and then "able to write" notification that had to be manually closed even though everything ran properly.

Another user has "path to SAS" -CONFIG "path to sasv9.cfg" -nosplash -batch -sysin %n which works on her virtual machine but not on others who have tried it.

The batch file solution will also move to Notepad++ or other coding editors I'm sure.
bob mcc.

Mofi · Jun 20, 2017#42017-06-20T17:24+00:00

UE help wrote:NOTE - If the %f, %p, %n, %e are lower case the filenames are passed as long filenames and should be put in quotes, i.e. "%f" or "%p%n" etc. If the %F, %P, %N, %E are in upper case the filename and path will converted and passed as the "8.3" short filename specification for maximum compatibility with DOS programs.

I strongly recommend that also for the Command line. Long file names and paths can contain a space character or &()[]{}^=;!'+,`~ which require enclosing the argument string in double quotes to be interpreted correct.

But never use "%p" in Directory edit field. The string defined here is not passed as argument to a script or executable. It is used directly to define the current directory for the process created to execute the command line. The current directory string is a separate function parameter on creating a process on which surrounding double quotes might not be automatically removed to get just the directory path as needed to set the current directory.

It is possible to use also UNC paths for current directory, see for example Use the Command Prompt with UNC Paths. But the registry value DisableUNCCheck is by default not defined and its default value is 0.

And with Windows 10 there are now already 3 shells available:

the classic Windows command line (console) as most often used on running console applications or batch files with support for Virtual Terminal Sequences since Windows 10 v1511,
the Windows PowerShell available by default since Windows Vista and supported in older versions also on Windows XP,
and the bash shell (only Windows 10 with anniversary update).

So the environment can be different in which a script or application runs even when multiple users use all Windows 10.