Sender:	ml AT delorie DOT com
Message-ID:	<34182532.1F7DCFE3@cdata.tvnet.hu>
Date:	Thu, 11 Sep 1997 19:06:58 +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 970910165448 DOT 10485C-100000 AT is>

Eli Zaretskii wrote:

> The proper vehicle to port fork/exec is spawn, it has the same parameter
> list and the same way of handling the arguments as exec, so making it
> work is easy.
> In the case that Perl calls the shell, you need to call `system' instead,
> that is how Make works, and experience shows that most of the time, this
> produces desired results.

This is a really good idea. I've tried it, and it's almost perfect. The
only problem is that if the user has a unixy shell and try to start a
program that is not exists, the shell will print a 'no such file' error
message. But I can live with that, because system really solves the
other problems nicely.

> You will probably need to review the code in Perl that decides whether
> the shell is required and see that it works correctly when SHELL or
> COMSPEC point to COMMAND.COM or [4N]DOS.  One of the problems is that %
> is a special character for these two, whereas I think sh doesn't treat it
> specially.  Another problem is that in DJGPP "..." is a wildcard, so you
> need to call `system' when you see it.

Now I use 2 character set, depending on whether the shell is unixy
(_is_unixy_shell()). I'm currently don't handle "..." specially because
most of us only use this to invoke djgpp programs, which will do the
globbing for themself.

> When Perl calls `exec', you don't need all the features of `system',
> because `exec' doesn't support redirection, pipes, quoting etc. anyway.

This is tricky under perl, because it handles differently exec with 1
parameter and exec with 2 or more parameters. In the first case perl
will look for the special characters, and exec the shell with the
command line. In the second case it just calls libc's execxx().

> > > 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!
> There isn't much you can do with that.  The only way to handle this
> so that it works for everybody is to invoke COMMAND.COM explicitly:
> 
>                 system ("command.com /c dir > dir.lst");

And what happens to the ANSIC ? :-)

> > 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.
> If there are cases, such as the perldoc script, where you must have
> reliable exit code, you don't have any choice but to change the script so
> it works.  perldoc is not just any script, it is how users should read
> the docs, so it must work reliably.  People indeed expect the scripts to
> work independently of the platforms, but when a script assumes too much
> about the underlying OS, it must be either changed so that it works on
> both platforms, or ported to DOS.  DOS and Unix just aren't alike enough,
> sorry.

Perl 5 has a nice variable called $^O which contains 'dos' in the djgpp
version. So I could solve this problem too.

Thanks for your patience and the ideas, they helped me a lot.

bye, Laszlo

- Raw text -