On Sat, 27 Apr 2019 01:14:29 +0100 Harald van Dijk <harald@xxxxxxxxxxx> wrote: HvD> I don't believe there is any requirement for your expectation and HvD> several other shells share this behaviour, but agreed that it would be a HvD> nice improvement to avoid this. Yes, this is certainly just an expectation and not something guaranteed by POSIX, but it looks like a very reasonable expectation to me. And, speaking of the other shells, all of the ones I tested (bash, ksh, zsh) do keep the lines together. HvD> Please keep in mind that even without this, you would not have HvD> deterministic output. The commands in a pipeline could be output in any HvD> order, even if each command would be output on its own line. In theory, it seems like you're right and it should be possible, but in practice it just doesn't seem to ever happen, i.e. the output is always in the same left-to-right order. Maybe there is something that implicitly serializing the output from the pipeline components either in the shell or in the kernel? I admit I haven't dived into this deep enough to really find out, the fact that the order remains always the same in practice is good enough for me. HvD> The #ifdef notyet is more than is needed for this. The output mechanism HvD> already supports buffering. It's easy to adapt this to work for xtrace HvD> output as well. Ah, I did see support for buffering but I didn't realize we could just use it unconditionally for "preverrout" as I thought it was supposed to be some kind of copy of stderr, and so remain unbuffered. Looking at this more carefully now, I see that "preverrout" is really only used for xtrace output (I wonder why isn't it called "xtraceout" then...), so making it buffered definitely looks like the right thing to do and it's much simpler than any alternatives I had come up with, thanks! HvD> You'd only run into issues if you have a command string HvD> that's larger than the buffer size, but I think that should be HvD> considered acceptable. Yes, I agree, this should be good enough in practice. The other approaches would still have some theoretical limitations anyhow (i.e. in-memory buffering would probably still use some fixed buffer size and writev() would be limited to IOV_MAX pieces of output). HvD> As a proof of concept that should clearly not be committed in its HvD> current form, please see the attached patch. Thanks, this is indeed much simpler than what I had in mind and I can confirm that it does work. What prevents this patch from being applied in the current form exactly? Thanks again, VZ
Attachment:
pgpGcVwbQlPTt.pgp
Description: PGP signature
