Re: bin/38004: /bin/sh truncates a message for unobvious reasons

[David Holland <dholland-bugs%netbsd.org@localhost>]

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: 
Subject: Re: bin/38004: /bin/sh truncates a message for unobvious reasons
Date: Sat, 1 Sep 2018 23:00:53 +0000

 On Sat, Sep 01, 2018 at 09:55:01AM +0000, Robert Elz wrote:
  >  This is the oldest remaining open /bin/sh related PR (that I know about
  >  anyway) so it is probably time to deal with it (I have skipped it up to now
  >  as it is really such a minor issue).
 
 Right...
 
  >    | One of these days I'm intending to rework the parser, since it does
  >    | quite a lot of unclean things (see for example PRs 19832 and 35423)
  >    | and I'll fix this properly then.
  >  
  >  10 years have passed (and a bit more) and that reworking ie yet to
  >  happen ... the PRs mentioned (well, that PR, even though it had multiple
  >  numbers, that was just one issue) has been fixed, and the PRs closed.
  >  
  >  The parser is not really all that bad, and while it has had tweaks over
  >  the past few years, and may eventually get a few more, they are no more
  >  than tweaks, and do not amount to a "reworking" .... and I don't think we
  >  need that.
 
 Yeah, that's what my todo list is like. :-(
 
 My conclusion when I looked at the parser then was that I should write
 a new one; but it was doing fairly regrettable things at the time and
 I have high standards for parsers.
 
 It does not have the symptoms now that it did then, in any case, so
 while I might still do that sometime it's no longer even half a
 priority.
 
  >  So, what I propose to do is to make that small algorithm just a
  >  fraction smarter (mostly with compile time tests, so no extra
  >  executable code needs to run, just like the "sizeof() < 100" tests
  >  now) but with the result that we save more (say a miniumm of up to
  >  about 50 chars) and have what is saved still depend upon
  >  MAXCMDTEXT (which is the same as the sizeof()) but in a slightly
  >  less obnoxious/brutal way than it is now.
 
 That seems fine.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost