[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/38004: /bin/sh truncates a message for unobvious reasons
The following reply was made to PR bin/38004; it has been noted by GNATS.
From: David Laight <david%l8s.co.uk@localhost>
Subject: Re: bin/38004: /bin/sh truncates a message for unobvious reasons
Date: Sun, 13 Apr 2008 21:30:53 +0100
On Sun, Apr 13, 2008 at 03:05:02AM +0000, David Holland wrote:
> The following reply was made to PR bin/38004; it has been noted by GNATS.
> From: David Holland <dholland-bugs%netbsd.org@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
> Subject: Re: bin/38004: /bin/sh truncates a message for unobvious reasons
> Date: Sun, 13 Apr 2008 03:03:59 +0000
> On Tue, Feb 12, 2008 at 06:35:01PM +0000, David Laight wrote:
> > > >Fix:
> > > +#if 1
> > > + len = sizeof(ps->cmd);
> > > +#else
> > > if (iflag || mflag || sizeof ps->cmd < 100)
> > > len = sizeof(ps->cmd);
> > > else
> > > len = sizeof(ps->cmd) / 10;
> > > +#endif
> > When is this a problem?
> > IIRC the purpose of the test is to speed up shell scripts - where it
> > is really pointless regenerating the command line in this form at all.
> Shouldn't the proper fix for that to be to either save a copy of the
> original command line string, or to only produce the string when it's
> needed? Or am I missing something obvious?
It needs the command string after substitutions, this only exits as a
tree, and the tree nodes are allocated from a 'stack allocator' and
are all thrown away (by resetting the base) once the comand is started.
Thus you have to walk the tree nodes to generate a printable string.
(I'm sure Mr Bourne's shell didn't use this sort of parser!)
David Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |