Mail Archives: djgpp-workers/2000/10/28/15:52:19
At 09:25 AM 10/28/00 +0200, Eli Zaretskii wrote:
<Snipped>
>Note that popen/pclose from our libc also redirect handles with
>dup/dup2 and call system() to run the subsidiary program.
I guess Laszlo put those in before the current popen/pclose were
available. Better, I think, if we try to use what's in libc, so that
future changes aren't lost to perl. I'll try removing his
perl-specific versions and make sure everything still works.
If it turns out we need to use "exec("sh -c 'command...'")" or
"spawn...("sh -c 'command...'")" to duplicate *ix behavior, then I can
put the special versions into perl only, leaving libc alone.
>> So DJGPP perl is using strictly system(), and now I need to
>> find out what perl uses elsewhere. And maybe what a *ix
popen/pclose
>> really use.
>
>I'd expect a Unix system to do this inside popen:
>
> call pipe() to open a pipe
> call fork() to start the child program
> in the child-program's branch of fork, call exec("sh -c
> 'command-line'")
> in the parent-program's branch, read and write the pipe
> when wait() says the child exited, close the pipes and cleanup
Well, glibc "iopopen.c" seems to do pretty much exactly that, anyway.
Is there any way (at present) to override system()'s use of "bash
tmpfile" or "sh tmpfile", say if the command line is short enough to
stay within DOS commandline limits? What about just for power users
who have set up CONFIG.SYS to use the "command.com" switch
"/u:255"? I'd bet there is a way to determine if that was done
*somewhere* in the DOS internals.
Just speculating here. I still have not determined just exactly how
perl implements open(fh, "echo #foo|"), so we are still lacking
critical information needed to determine a path to take.
More as I get it.
---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
pjfarley AT banet DOT net)
- Raw text -