Bug 164800 - sys-apps/pciutils - make update-pciids quieter
|
Bug#:
164800
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: base-system@gentoo.org
|
Reported By: prote@fmi.uni-stuttgart.de
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: sys-apps/pciutils - make update-pciids quieter
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-02-01 09:37 0000
|
On machines that have not installed some of the tools (e.g. curl) checked in
/etc/cron.monthly/update-pciids the cron daemon sends me the warning
which: no curl in (/sbin:/bin:/usr/sbin:/usr/bin)
Fix: In /usr/sbin/update-pciids all
which curl >/dev/null
etc. should be changed to
which curl >/dev/null 2>&1
Reproducible: Always
And a second thing:
I don't call it a bug but I would prefer /etc/cron.monthly/update-pciids to
work silent if no error occurs. So I suggest adding the switches
-q/--quiet to wget
-s/--silent to curl
in /usr/sbin/update-pciids.
*** Bug 164859 has been marked as a duplicate of this bug. ***
added a -q flag and the cronjob now uses it
(In reply to comment #3)
> added a -q flag and the cronjob now uses it
Sorry! But that only removes the statistics of curl or wget. I still get
# /usr/sbin/update-pciids -q
which: no curl in (/sbin:/usr/sbin:...)
on machines without curl. I think there is no sense in telling me that I
haven't tool A on my machine if an alternative tool B is used anyway.
So all the "which tool >/dev/null" in /usr/sbin/update-pciids should be changed
to "which tool >/dev/null 2>&1" and only if none of the alternative tools is
found an error should be reported.
(In reply to comment #5)
> give 2.2.4-r2 a spin eh
SpanKY: Yes, the new update-pciids is nice and quiet. It doesn't cause
unnecessary mail to be sent from the cron job. Thanks!
(In reply to comment #5)
> give 2.2.4-r2 a spin eh
>
Sorry, it's me again! And I once again reopened this bug because I still get
# /usr/sbin/update-pciids -q
which: no curl in (/sbin:/usr/sbin:...)
on machines without curl. "which curl >/dev/null" (and all the other "which
...")
was changed to "which curl >&2 >/dev/null". I'm not an bash expert but isn't
this:
Duplicate stdout to stderr and redirect stdout to /dev/null.
And so stderr still is not sent to /dev/null.
As there is no executable "tool" on my machine I experimented a bit:
a) My original suggestion:
# which tool >/dev/null 2>&1
#
b) The current version:
# which tool >&2 >/dev/null
which: no tool in (/sbin:/usr/sbin:...)
c) Alternative solution:
# which tool >&2 2>/dev/null
#
So maybe just a forgotten '2' at the first '2>/dev/null' and the
copy-and-paste?
I think a very bad idea to activate by default ANY script that uploads that
either from the Internet to your computer. In installation phase package should
report about that feature, but did not activate it by default.
(In reply to comment #8)
> I think a very bad idea to activate by default ANY script that uploads that
> either from the Internet to your computer. In installation phase package should
> report about that feature, but did not activate it by default.
>
--- /root/update-pciids.orig 2007-04-12 19:55:07.000000000 +0400
+++ /etc/cron.monthly/update-pciids 2007-04-12 19:55:50.000000000 +0400
@@ -1,2 +1,9 @@
#!/bin/sh
-exec /usr/sbin/update-pciids
+
+if [ -e /etc/conf.d/pciutils ]; then
+. /etc/conf.d/pciutils
+fi
+
+if [ "$PCIUTILS_UPDATE_IDS" == "yes" ]; then
+ exec /usr/sbin/update-pciids
+fi
this bug has nothing to do with the network issue
fixed quiet issue in 2.2.4-r3
Now I like it.
Many thanks!
*** Bug 180530 has been marked as a duplicate of this bug. ***
Since my bug was dup'd against this bug, is there any chance that the newer
package that doesn't have the bug, will be marked stable if that's the only
change, or for the very least, an -r3 will be provided for 2.2.3 to fix this?
After all, this bug is there for 4 months now...
Thanks
it's been around long enough, we can stabilize ... i'll file a stabilization
bug
*** Bug 182439 has been marked as a duplicate of this bug. ***
*** Bug 186764 has been marked as a duplicate of this bug. ***