Sender: ml AT delorie DOT com
Message-ID: <34167F53.5623095F@cdata.tvnet.hu>
Date: Wed, 10 Sep 1997 13:06:59 +0200
From: Molnar Laszlo <molnarl AT cdata DOT tvnet DOT hu>
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: DJGPP workers <djgpp-workers AT delorie DOT com>
Subject: Re: a patch for system()
References: <Pine DOT SUN DOT 3 DOT 91 DOT 970910115017 DOT 9494B-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

> > I think it's dangerous using system() to call builtin shell
> > commands.
> But that's what ANSI C requires!  It says (in para 7.10.4.5) that
> `system' passes its argument ``to the host environment to be executed
> by a COMMAND PROCESSOR''.  So we cannot disable this behavior.

OK. Then I can't use libc's system(). In fact, when a perl script says
system("something"), Perl won't call the system() in libc on UNIX
platforms either. It just uses fork/exec (or spawn on OS2), if it
doesn't see a suspicious character. Else it will call 'sh' (or CSH if
the builder(!) of the executable had csh). So using builtin shell
commands can fail.

I just tried to use djgpp's system() because I didn't want to play with
spawn() when your system() would make most of the job for me. The only
problem is this "last resort".
 
> Also, DOS users are accustomed to that, and `system' does a fairly
> good job when they do.  Other DOS compilers *always* call COMMAND.COM
> inside their `system', so people are used to say things like
> ``system("dir > dir.lst")'' and expect that to work.

Actually it doesn't work for me, because my SHELL is set to bash.

> > Yes, but the perl doc says, that system() won't call the shell if not
> > needed.
> The docs can say that the DOS version behaves differently.

But why it only behaves differently if the user has an unixy shell ?!

> > There is a
> > script in the perl distribution called 'perldoc' to view the
> > documentation. It tries to call several pagers (first 'less', then
> > 'more'). If the user doesn't have less and doesn't set SHELL to bash, he
> > can't use it, because the script tries to call 'less filename.something'
> > and won't notice that the call failed, because of command.com. So the
> > user won't see the documentation :(
> Change that to "less.exe", "more.exe", etc. and it will work even with
> COMMAND.COM.  I don't think a single script is a reason enough to make
> such a crucial change in `system'.

Ok, that would solve the problem with this particular script. But it was
just an example, there can be more scripts with the same problem out
there. And this ".exe" suffix is a little unportable. People expect to
use their script unchanged on different platforms.

> > What do you think about a new flag instead of __system_emulate_command?
> > If someone knows what he is doing... (or thinks he knows :)
> What would this flag do?

It would disable this "last resort".

> > Why not if he uses another shell's builtin command?  If someone wants to
> > use a builtin, he must call the shell directly. It's quite normal, isn't
> > it?
> This is correct only for `spawn' and `exec' families of functions.
> ANSI requires that `system' should know how to run any command that
> the command processor (i.e., the shell) understands.

But the programmer can't know what kind of shell the user will use. And
as we saw system("dir") can fail!

ML