Message-Id: <4.3.1.0.20001029163249.00b1c670@pop5.banet.net> X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 29 Oct 2000 17:11:25 -0500 To: djgpp-workers AT delorie DOT com From: "Peter J. Farley III" Subject: Re: Bash 2.04 beta 6a Cc: Eli Zaretskii In-Reply-To: References: <4 DOT 3 DOT 1 DOT 0 DOT 20001028153622 DOT 00b18a90 AT pop5 DOT banet DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk At 08:17 AM 10/29/00 +0200, Eli Zaretskii wrote: >On Sat, 28 Oct 2000, Peter J. Farley III wrote: >> 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)