Date: Sun, 14 Sep 1997 17:07:44 +0300 (IDT) From: Eli Zaretskii To: Molnar Laszlo cc: DJGPP workers Subject: Re: a patch for system() In-Reply-To: <34182532.1F7DCFE3@cdata.tvnet.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 11 Sep 1997, Molnar Laszlo wrote: > 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. No, that's wrong. Arguments passed via `spawn' are NOT globbed by the child. This was one of the significant changes in v2.01 that broke compatibility with v2.0. The reason for the change was POSIX compliance: programs invoked through `exec' on Unix are NOT called via the shell, and, since globbing on Unix is done by the shell, arguments passed through `exec' aren't globbed. (The DJGPP startup code has a means of knowing whether the program was called by `spawn' or by `system', and doesn't call the filename- globbing function in the former case.) So, if the command line includes ANY wildcard characters at all, you MUST call the child through `system', or it won't glob the arguments. > > 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(). No, not tricky at all: just call `system' whenever Perl calls the shell, and call `spawn' otherwise. When there are 2 or more arguments, none of them could be pipe, redirection etc., and if they are, they are meant to be passed verbatim to the child program. Perl just assumes that the shell is always called with a single argument: its full command line. > > system ("command.com /c dir > dir.lst"); > > And what happens to the ANSIC ? :-) Nothing happened, because system("dir") also works; it's just that the effects are different. in contrast, your suggestion was to make system("dir") fail, which is against ANSI C.