Like said, this is a generic problem in rpm where diagnostic messages are
dumped on stdout. Other similar examples include (but not limited to):
```
[pmatilai@sopuli ~]$ rpm -q --whatprovides bar
no package provides bar
[pmatilai@sopuli ~]$ touch foo
[pmatilai@sopuli ~]$ rpm -qf foo
file
Closed #615.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/615#event-2050402248___
Rpm-maint mailing list
I think that the patch fixes an ERROR in user interface of rpm utility.
When a user asks for a list of package's files he wants to get exactly the list
of files, doesn't he? And if there's no files in the package then he wants to
get an empty output, doesn't he? Why instead of empty output he
For the same reason there is ls when a script uses *.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> You can get the list of files with rpm -q --qf='[%{FILENAMES}\n]'. There is
> nothing dirty about that, those are the building blocks.
So, for what `rpm -ql` ?
And, as example same behaviour of `ls` (Why you have OWN WAY and why this
solution right?):
```Bash
$ mkdir empty_dir
$ cd
You can get the list of files with rpm -q --qf='[%{FILENAMES}\n]'. There is
nothing dirty about that, those are the building blocks.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> I don't see that this is the rpm binary's issue
I completely disagree with this imprisonment.
You (or your team ) made strange, unpopular decision that makes problems for
simple (popular, expected) case. Other software put this warning to stderr or
just return nothing with success code.
You
if the problem is an empty file being queried, why not solve teh problem where
the action occurs (before the test), with something simple like:
[ -s $ARG ] && ...
I don't see that this is the rpm binary's issue
--
You are receiving this because you are subscribed to this thread.
Reply to
> You can use rpm -q --qf='%{FILENAMES:arraysize}\n' to get the number of files.
Ok. And what about getting a list of included files? Do you have a dirty trick
for that? And why we can't just trust `rpm -ql` to do this simple task?
--
You are receiving this because you are subscribed to this
> changing them _will_ break some scripts that expect them there
No, you can't even rely on this behavior in scripts, because this message
(contains no files) is locale-dependent. You can't use it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
You can use rpm -q --qf='%{FILENAMES:arraysize}\n' to get the number of files.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This (spewing "helpful" messages into stdout) is a much broader problem than
just this one message, and we should address them all at once or not at all. As
much as mostly everybody hates these "helpful" messages, changing them *will*
break some scripts that expect them there, so if/when
Conan-Kudo approved this pull request.
LGTM
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Isn't that what the `--quiet` switch is for...?
No, definitely no. Because --quiet switch suppresses all output, so the output
of rpm -ql of a normal package with a set of files included in will be also
empty.
Example:
$ rpm -ql bzip2-devel-1.0.6-28.fc29.x86_64 | wc -l
6
$ rpm -ql --quiet
Isn't that what the `--quiet` switch is for...? I'm not sure this patch makes
sense...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
15 matches
Mail list logo
