5

Consider the following batch file test.bat:

CD C:\SOFTWARE
program.exe

This script is run from C:\ELSWHERE

C:\ELSWHERE> C:\test.bat

After the script exits the current working directory is now C:\SOFTWARE and not the previous working directory C:\ELSWHERE.

The script changes the working directory to C:\SOFTWARE because program.exe requires config.ini which is located in C:\SOFTWARE and locates it using the current working directory. If the software program.exe were to be run directly from, say, C:\ or C:\ELSWHERE using its absolute path name, the program will be unable to read its config and throw an error. The solution to this is to CD to the C:\SOFTWARE folder first and run the program from there.

The problem with doing this in a batch file is that this also changes the working directory of the previous environment, be it the host COMMAND.COM working directory or another batch file.

This is not a problem from an NT-based command prompt which has access to pushd and popd, along with other useful environment variables to preserve the old working directory. But is it possible to do this within the constraints of the old MS-DOS\Win9x command.com?

Zhro
  • 837
  • 2
  • 15
  • 31
  • Can't you execute the batch file in its own shell so that it has no effect on the calling batch, like this: `cmd /c script.bat`. In such an old system CMD might be `command.com` or whatever. – harrymc Mar 07 '22 at 14:30
  • There is only `command.com`. The `cmd.exe` interpreter is from Windows NT. And surlrisingly, using `command.com /c script.bat` clobbers the working directory of the parent interpreter. I would have expected this to work as well. – Zhro Mar 07 '22 at 14:53
  • I found a [repository of Windows 95 utilities](http://www.retroarchive.org/garbo/pc/dirutil/index.html). I don't have of course the environment for testing any of them, but you could try all those that have the string "Change Directory" in their description. Several of them are described as "makes changing directories much easier". Who knows, someone might have written a similar utility to pushd/popd. – harrymc Mar 07 '22 at 15:13
  • 2
    @VomitIT-ChunkyMessStyle This FOR variable expansion appears to be an NT extension and doesn't work with the old DOS interpreter. – Zhro Mar 08 '22 at 03:16

1 Answers1

2

This even works with MSDOS6.22

pwd.bat

@echo off

@echo @prompt @set drive=$N:$_ @set pwd=$P> temp.bat
%comspec% /c temp.bat > temp2.bat
call temp2.bat
del temp.bat
del temp2.bat
echo %PWD%

It stores the current directory into the pwd variable and the current drive into the drive variable.

This can be used to restore the previous directory.

In your case

@echo off
call pwd.bat

CD C:\SOFTWARE
program.exe

%drive%
cd %pwd%
jeb
  • 387
  • 2
  • 12
  • This is excellent, except that `CD` can't be used to switch the active drive letter, and the `\D` switch is unavailable until NT. So if a script changes drive letters, the old path cannot be restored using the full path name. Is it possible to extract the first character of the pwd (the drive letter) to a variable as well? This would provide a means to a complete solution by ensuring that the correct drive letter can be selected. – Zhro Mar 08 '22 at 05:44
  • @Zhro I added the drive variable. It could be extracted, but using `prompt` to create it, looks easier – jeb Mar 08 '22 at 05:54
  • Very impressive and clever use of `prompt`! I was unable to find a way to extract substrings to isolate the drive letter without the use of NT extensions. This is a great workaround. – Zhro Mar 08 '22 at 06:25
  • @Zhro Splitting with old batch is possible, but much more complex – jeb Mar 08 '22 at 06:41
  • There is some kind of side effect with this. The `@SET pwd=` line of `pwd2.bat` has an extra LF (line feed) character, and this is creating a problem. The last three bytes are `0A 0D 0A` which is `LF CR LF`. The line feed character is being assigned to the `pwd` as a result. I worked around this by adding an extra `$_` before the file redirection, pushing the LF to the next line. The problem this creates is that `CD "%pwd%"`, throws an error because the line feed becomes part of the quoted path. Do you have any idea where this character is coming from and if it can be avoided entirely? – Zhro Mar 08 '22 at 10:58
  • I tested it with MSDOS 6.22, there is a trailing space assigned, this is expected, because there was a space between the last character and the redirect `...$P > temp.bat`. When I remove it, it works for me – jeb Mar 08 '22 at 12:08
  • The problem isn't the space but an extra line feed character. It's not rendered by EDIT but is visible as a black square in Windows 98 notepad. It can also be viewed with a hex editor. Note that it may also be invisible in modern Windows notepad (tested on Windows 11). – Zhro Mar 08 '22 at 13:21
  • @Zhro Strange, on modern windows it's much more complicated to store a single LF into a variable. Are there differences, when you remove the space between `@set pwd=$P > temp.bat` to `@set pwd=$P> temp.bat` ? – jeb Mar 08 '22 at 16:49
  • I tried this in my testing. It just shifts the LF to the left. – Zhro Mar 09 '22 at 08:38