From: "Tim Van Holder" To: Cc: Subject: Re: Possible bash issue Date: Sat, 19 May 2001 01:30:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <5137-Fri18May2001232658+0300-eliz@is.elta.co.il> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 > > Also, isn't the transfer buffer supposed to be an upper limit to > > the number of arguments, or is that only when invoking DOS apps? > > Yes, the transfer buffer (minus the size of the environment) is the > limit when invoking DJGPP programs (DOS programs have their usual > 126-char limit). But IIRC there's one exception: when Bash invokes > Bash (or some other Unixy shell). I think if you step through the > code, you will see that Bash calls `system' (perhaps via `popen'), and > `system' invokes Unixy shells via a disk file, like this: > > sh disk-file > > where disk-file holds the entire command line. Clearly, when invoked > like this, the sky is the limit ;-) Hmm - that explains the extreme slowdown :-) Doesn't explain why bash would crash though (unless it freaks out if given a huge disk file as input - it doesn't pull it all into memory, does it?) > In other words, to be effective, this test should invoke some other > DJGPP program, not a shell. (But perhaps someone should actually step But what external program could you call (portably!) that would still allow such a deduction to be made? I think I'll just lower the loop limit and be done with it. I don't think anything bad will come from saying DJGPP is limited to 18K worth of command line.