Re: [lmi] Making "dash -x" more atomic

[Vadim Zeitlin]

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

GC> On 2019-04-25 13:51, Vadim Zeitlin wrote:
GC> > On Thu, 25 Apr 2019 12:39:06 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567648
GC> 
GC> 
GC> | The subshells in pipeline prints their own commands before executing
GC> | it, using multiple syscalls giving possibility of intermixed output
GC> | when context switches happen in between...
GC> 
GC> > https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/eval.c#n854
GC> > 
GC> >  As you can see, if we just combined outstr(), eprintlist() and outcslow()
GC> > into a single syscall, the problem would be solved. Of course, it would
GC> > still take time for the fix to be accepted and then propagate into Debian,
GC> > but maybe it still would be worth to do it?
GC> 
GC> It's certainly worth it.

 Just an update: the good news is that there is a very simple (modifying
one line and removing 2 other ones) patch fixing the problem in dash, see
the end of this post:

        https://www.mail-archive.com/address@hidden/msg01880.html

However there are 2 problems: the first one is that the patch hasn't been
applied yet because of some (IMO misplaced) concerns about the inefficiency
of having another buffer and second one is that it turns out that even if
the output consists of the same lines, the order of the lines can still
very: and it does it not only in dash, but in bash too (I didn't mention it
in my reply to dash mailing list, but zsh does produce consistent, albeit
reversed compared to dash/bash, output even after hundreds of thousands of
iterations).

GC> Logs that are identical clearly show no regression. Logs that are "almost"
GC> identical require manual effort to compare.

 So there doesn't seem to be any way to generate perfectly reproducible
xtrace output from a pipeline in neither dash nor bash. However the line
order change is infrequent and can be dealt with by "git diff --no-index
--color-moved=plain", so it shouldn't be too bad once some version of the
patch above will be applied to dash and propagates to the next version of
Debian (in the meanwhile, nothing prevents us from rebuilding Debian
package with this patch ourselves and using it instead of the standard one,
of course).

 Regards,
VZ