Mail Archives: djgpp/1997/07/13/13:35:27
On Thu, 10 Jul 1997, Cesar Scarpini Rabak wrote:
> Searching further we figure out that system from DJGPP libc searches first
> the path for an executable matching the system call, and in the bin sub-dir,
> there it was dir.exe (a specialized version of ls, btw).
This is a feature, and the above describes it correctly.
> Whereas the libs docs inform that system would search first, my coleague
> points out that people rised in the MS-DOS world can only think of DIR as an
> internal command!
>
> I wonder if this should not be more emphasized in the docs,
How would you suggest to emphasize this more? It is explained on the
same page where `system' is documented, so if your friend reads the
docs before using any function (and if not, he should), he will see it
right away.
Documenting this in any other place will IMHO run higher risk of going
unnoticed. But please feel free to make any suggestions you see fit.
> or this
> behaviour would be considered a bug (a very subtle one, as in a machine w/o
> DJGPP the program would works as charm!).
It's not a bug, it's a feature, and it is there for a very good
reason: it allows you to have substitutes for internal DOS commands
without any hassles (like patching COMMAND.COM by a binary editor).
For example, many Unix-born Makefile's use `echo', but they assume
Unix-style echo which is far beyond what the built-in ECHO knows.
Without the above feature, too many things will break.
I think the correct solution is to call the COMMAND.COM's DIR
explicitly, like so:
system("command /c dir /w/ogne/-p/s > dirs.txt");
A portable program should never assume anything about the utilities
installed on target machine. In this case, your friend shouldn't have
assumed that COMMAND.COM is the shell. For example, somebody might
use Bash as their shell, and then the program would fail also, even if
no `dir.exe' is installed.
- Raw text -