Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rpm --eval ignores write errors on stdout #1444

Closed
DemiMarie opened this issue Nov 18, 2020 · 1 comment
Closed

rpm --eval ignores write errors on stdout #1444

DemiMarie opened this issue Nov 18, 2020 · 1 comment
Assignees
Labels

Comments

@DemiMarie
Copy link
Contributor

rpm --eval 1 >/dev/full; echo $? shows 0 and no error message.

@dmnks dmnks self-assigned this Jan 15, 2021
@pmatilai pmatilai added the bug label Jan 15, 2021
dmnks added a commit to dmnks/rpm that referenced this issue Mar 1, 2021
Since --eval only has one job - to actually *print* something to stdout,
we should fail completely if that's not possible due to an external
error, instead of just not printing anything.  One particular case is
redirecting stdout to a file on a file system that's full (generating
the ENOSPC error).

In order to be able to detect such errors, we need to flush the stream
buffer first; that's because normally, if stdout is not referring to an
interactive device (a terminal), it is block-buffered, as opposed to
line-buffered.
dmnks added a commit to dmnks/rpm that referenced this issue Mar 1, 2021
Since --eval only has one job - to actually *print* something to stdout,
we should fail completely if that's not possible due to an external
error, instead of just not printing anything.  One particular case is
redirecting stdout to a file on a file system that's full (generating
the ENOSPC error).

In order to be able to detect such errors, we need to flush the stream
buffer first; that's because normally, if stdout is not referring to an
interactive device (a terminal), it is block-buffered, as opposed to
line-buffered.
pmatilai pushed a commit that referenced this issue Mar 4, 2021
Since --eval only has one job - to actually *print* something to stdout,
we should fail completely if that's not possible due to an external
error, instead of just not printing anything.  One particular case is
redirecting stdout to a file on a file system that's full (generating
the ENOSPC error).

In order to be able to detect such errors, we need to flush the stream
buffer first; that's because normally, if stdout is not referring to an
interactive device (a terminal), it is block-buffered, as opposed to
line-buffered.
@dmnks
Copy link
Contributor

dmnks commented Mar 25, 2021

Forgot to reference this issue directly in the above commit (with a "Fixed: #1444" in the commit message), so closing manually.

@dmnks dmnks closed this as completed Mar 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants