Date: Tue, 30 Aug 94 11:23:48 EDT
From: jes AT mbio DOT med DOT upenn DOT edu (Joe Smith)
Posted-Date: Tue, 30 Aug 94 11:23:48 EDT
To: babcock AT cfa DOT harvard DOT edu
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: djgpp system call


I guess this is a little complicated because Unix can assume that a
minimal sh is always present: the only man pages I have simply specify
that 'sh(1)' is called by system().  Does anyone who has access to
POSIX care about this enough to look up what the standard behavior is?
The problem with DOS is that the standard shell is rather pitiful and
one would very much like to use something like sh and have it work
transparently with Unix tools (e.g., make would benefit greatly if it
could call a real shell).  Respecting the setting of SHELL is one way
of doing that.  It seems to me that if SHELL is set, then it would be
reasonable to assume that the specified shell is a Unix-style shell
that accepts '-c' (but you could always check for the string
'COMMAND.COM' just be sure).

> But what if you have set SHELL=command.com?

Why would you do that?  The 'SHELL=' statement in CONFIG.SYS doesn't
set the environment variable does it?  COMSPEC is the proper way to
locate COMMAND.COM.  I believe COMSPEC should always point to
COMMAND.COM and it should be set even if the system shell (as defined
by CONFIG.SYS) is not COMMAND.COM.

> I think that your request would be better met at the application
> level than at the extender level.

I though we were talking about the behavior of the system() library
function?  Again, I don't know what POSIX says, but I think it's a
safe bet that most of the source code used with djgpp will call
system() with a command string that assumes sh semantics.  It might be
asking a lot to expect all of the implied Unix-ness to exist on a DOS
system, but it's not that hard to get most of it.  If you wire
COMMAND.COM into system(), then you're guaranteed to have practically
none of it.

<Joe