Re: [lmi] Making "dash -x" more atomic (was: Navigate by color in `git-diff --color-moved=plain`)

[Vadim Zeitlin]

On Thu, 25 Apr 2019 12:39:06 +0000 Greg Chicares <address@hidden> wrote:

GC> I think it would be premature to switch from dash to 'bash --posix'.
GC> This appears to be only a sporadic formatting problem with 'dash -vx'.
GC> (Perhaps it's this:
GC>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567648
GC> .)

 Yes, this is definitely the same bug, thanks for finding it. Unfortunately
it looks unlikely that it's going to be fixed soon, considering lack of
activity since 2013. OTOH I couldn't find any bug tracker for it nor any
mention of this bug in https://www.mail-archive.com/address@hidden/,
so perhaps it would be worth reporting it there, seeing that dash is still
being maintained (see https://git.kernel.org/pub/scm/utils/dash/dash.git
for some recent commits).

 BTW, I've used the strace command from the comment in the bug report above
with zsh and can confirm that it doesn't suffer from this problem neither.
And, just to be complete, both bash and zsh output $PS4 twice for the
commands executed in the subshell, while dash does it only once. Moreover,
zsh also outputs the part of the current command from the parent shell,
which makes its output even more informative but also even more difficult
to read. Who knew that shell support of -x option could be so
complicated... (except for people who know that anything related to Unix
shells is complicated, that is).


GC> I wouldn't suppose that bash has no cosmetic problems of its own,
GC> or has fewer defects overall than dash. And keeping the "#!/bin/sh"
GC> shebang presumably helps shellcheck guard against portability issues.

 Yes, I like using /bin/sh for this and other reasons, but this bug is
pretty annoying because it makes the output non reproducible. I don't see
what can we do other than trying to fix it ourselves in dash. I've had a
look at dash sources, and, to my surprise (I expected worse from 30 year
old C codebase), they're not horrible and I could find the place where the
problem happens relatively quickly (it still took me some time because grep
wasn't finding anything due to several years of macros used in the code, as
is traditional in C, but I finally made my way through them) and it's in
the block starting here:

https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/eval.c#n854

 As you can see, if we just combined outstr(), eprintlist() and outcslow()
into a single syscall, the problem would be solved. Of course, it would
still take time for the fix to be accepted and then propagate into Debian,
but maybe it still would be worth to do it?

 Please let me know if you think it would,
VZ