delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/10/29/17:28:44

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" <pjfarley AT banet DOT net>
Subject: Re: Bash 2.04 beta 6a
Cc: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
In-Reply-To: <Pine.SUN.3.91.1001029080733.3725A-100000@is>
References: <4 DOT 3 DOT 1 DOT 0 DOT 20001028153622 DOT 00b18a90 AT pop5 DOT banet DOT net>
Mime-Version: 1.0
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

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019