Re: Can't pipe output of pasta --version

[Jon Maloy <jmaloy@redhat.com>]

On 2025-05-28 03:45, Stefano Brivio via user wrote:
> [Cc: Paul as author of d0006fa78]
> 
> On Wed, 28 May 2025 12:25:10 +1000
> David Gibson<david@gibson.dropbear.id.au> wrote:
> 
>> On Tue, May 27, 2025 at 05:21:19PM +0000, John Radley (jradxl2) wrote:
>>> Hello,I can't pipe output like this:-
>>> $ pasta --version | grep pasta<blank!>
>>> but this works:-
>>> $ sudo apt install expect
>>> $ unbuffer pasta --version | grep pasta
>>> pasta 2025_05_12.8ec1341-9-g3262c9b
>>>
>>> If this is the intended action, please can you tell me why?
>> Ouch.  No, that's not intended.
>>
>> I initially assumed this was because we were sending the version
>> information to stderr instead of stdout, but that's not the case.
>>
>> This is a bug introduced by d0006fa78 ("treewide: use _exit() over
>> exit()").  For --version we're displaying the information with
>> fprintf(), then immediately exiting with _exit().  When writing to a
>> pipe, stdout is buffered.  Normally the buffer would be flushed before
>> exiting, but using _exit() bypasses that.
>>
>> We could fix this specific problem by adding an fflush(stdout) before
>> the _exit().  However, I worry that there might be other bugs we have
>> because we're not running libc installed exit handlers here and
>> elsewhere.  I was already a bit dubious about using _exit() by
>> default, and now I really don't think it was a good idea.
> Well, that's something we looked into (of course...), and (I?) concluded
> that we never needed to flush stdio, which is the only otherwise useful
> thing glibc handlers would do for us, and which kind of holds... except
> for this case. And maybe for --help or any "early" exit.
> 
> So we could fflush() as well in those cases, and just in those
> cases, with the added benefit that we don't need to add additional
> system calls to the permitted seccomp set, because if we exit early, we
> didn't install the seccomp filter yet.
> 
>> That said, I don't immediately have a better idea of how to address
>> the problem d0006fa78 was aiming to fix in the first place.
>>
>> Well... I'm on holiday at the moment, so I won't be fixing it.
>> Laurent & Stefano, I hope the analysis above is helpful.
> I'm on holiday too, I'll fix this later this week or next week, unless
> Paul is particularly inspired (or John wants to look into the issue a
> bit further and contribute a patch...?).

I'll take a look tomorrow.
/jon

> 
> -- Stefano
> 
> 
> _______________________________________________
> user mailing list --passt-user@passt.top
> To unsubscribe send an email topasst-user-leave@passt.top