Mail Archives: djgpp-workers/2000/10/29/17:28:44
At 08:17 AM 10/29/00 +0200, Eli Zaretskii wrote:
>On Sat, 28 Oct 2000, Peter J. Farley III wrote:
<Snipped>
>> I guess Laszlo put those in before the current popen/pclose were
>> available.
>
>I doubt that: our popen/pclose is mostly unchanged from what was
>released with v2.0.
>
>> 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.
>
>I'd suggest to as Laszlo first, in cased there's a good reason for
what
>he did.
OK, I will do that.
>> 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.
>
>The only difference between the above and what libc does now is the
-c
>switch. If that's the important difference, you could always say
>popen("sh -c 'command...'", ...) instead of just popen("command",
...).
>
>Note that by forcing "sh" into popen you force Perl users to install
>Bash, even if the commands they use don't require Bash. I don't know
>whether this is a problem.
I don't either. I suspect changes to do that would break a lot of
scripts that want/need to do things with COMMAND.COM, though. I would
be as leery as you about doing that.
>> 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?
>
>Before you embark on that journey, let's be sure this is what
causes >the different behavior. There are good reasons for the way
`system' >calls a Unixy shell (I forget the details, but the comments
there say >something about here-documents).
OK, that seems reasonable. I'll read up in system() myself to get more
familiar with the issue.
>> 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.
>
>Don't bet: you'd lose ;-).
Aw, shucks. And I though W. Gates was a reasonable fellow. ;)
>> 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.
>
>Yes.
Well, I did some more code reading yesterday, and the PerlProc_popen
procedure defined inside perl definitely uses 'exec("sh -c command")'
to run the command. I'm going to try to figure out how to use or copy
the perl code, since it has a lot of good code to determine *if* a
unixy shell is needed before it exec's with "sh -c". I suspect that
this procedure attempts to provide popen/pclose when the underlying
system doesn't, but I don't know that for sure yet. The code I saw is
deliberately bypassed for DJGPP with "#if !defined(DJGPP)" (among other
systems). I suspect I may have to make a number of other changes to
get the perl procedure not only defined but also used, so it may be
easier at first to just copy that code to the private DJGPP-only code
and see how it works there.
Bye for now.
---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
pjfarley AT banet DOT net)
- Raw text -