Mail Archives: djgpp-workers/1997/09/09/12:42:47
Eli Zaretskii wrote:
> > when don't need. So I simply check for some magic character in the
> > command line, and if I find none, I set __sys_flags to use
> > __system_emulate_command.
>
> Isn't this dangerous? The test to see whether the shell is required
> is much more complicated than looking for special characters. For
> example: is `:' a character that calls for the shell or not? If it
> is, you are going to call the shell for every DOS pathname which
> includes a drive letter; if it isn't, you will fail for commands that
> begin with a `:' (which only unixy shell knows about). And this is in
> no way a single example; see job.c from the GNU Make distribution, for
> an example of how a complete treatment of this issue looks like.
You are right, it can be dangerous. But Perl uses this way. It simply
checks for a character set (':' is not in the set..) and it calls
spawn() if the shell is not required. When someone wants to use a
builtin command, he sould call directly system with "/bin/sh....". I
think it's dangerous using system() to call builtin shell commands.
> I think the overhead of calling Bash is not too much to pay for
> correct operation. After all, we all know that whoever uses DOS
> *must* pay something for having GNU tools, right?
Yes, but the perl doc says, that system() won't call the shell if not
needed. And I already received a report from a guy, who patched my perl
binary(!) to use 4dos instead of sh.exe :)
> But I don't see any way to handle the problem with COMMAND.COM
> returning 0.
That's why I'd like to disable this branch of system(). 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 :(
What do you think about a new flag instead of __system_emulate_command?
If someone knows what he is doing... (or thinks he knows :)
> People who use Perl should be told to set SHELL to Bash, as God intended.
Too many fanatic out there, I'm afraid :(
> This isn't right, I think: it causes Perl to fail all the internal
> commands of the shell. Is this what you want? Does Perl on Unix fail
> to execute commands internal to the shell?
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?
> Another problem with this is that if the shell has its own places
> (other than $PATH) to search for its scripts, this patch breaks those
> cases also, if the name of the script gets here with no extension.
Yes. But I have to handle the problem somehow. And as I noticed, I can't
assume, that the users install bash.
Any idea?
Laszlo
- Raw text -