Actually, no, architecturally it shouldn't even work on MS-DOS from version 2.0 on. (Earlier 1.0 and 1.1 didn't implement subdirectories.) Of course, I don't know how far back we see any build of Perl for MS-DOS.
Each system() call with spaces in it results in a new instance of COMMAND.COM (or in NT-speak, CMD.EXE). It is that interpreter which takes the single string and parses it into execution. Perl wouldn't pass the "cd foo" string to perl's parent interpreter, and there is no cd.exe, so this is how it has to happen. Anything under that instance of the command interpreter has one "active directory" for each lettered device. This is lost when the command shell quits.
In Un*x, a process only sees the filesystem world as a single root, instead of several distinct lettered devices, and each process has its own current directory relative to that root.
--
[ e d @ h a l l e y . c c ]
| [reply]
[d/l]
[select] |
No. Under DOS, there's only one current directory (per drive) which is shared with all processes.
I suspected this when I posted Re^3: trouble with system commands but wasn't sure enough to contradict you and didn't have DOS installed so I couldn't check. I stashed this node away in my TODO.
As I now have DOS 6.22 running in an emulator, I thought to finally try it. I remembered right.
I don't have perl installed under DOS. However, I've compiled a C program that does a chdir("\\") call, and when I've ran it from the command prompt, the working directory in the shell has changed. I've got the same result when the C program did system("cd \\") instead, and also when I just did command /c cd\.
Just for the record, the current drive and the working directory of all drives are shared among processes, but the environment variables aren't. Also, if you start multiple DOS boxes under windows 3.11, each box has a separate working directory, but it is shared among processes in a single dos box.
| [reply]
[d/l]
[select] |