Bug 1276664
| Summary: | RFE: implement --ignore-missing for sha*sum -c | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> |
| Component: | coreutils | Assignee: | Ondrej Vasik <ovasik> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 23 | CC: | admiller, kdudka, kparal, kzak, ooprala, ovasik, pbrady, p, twaugh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-10-30 15:14:23 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Kamil Páral
2015-10-30 12:32:24 UTC
A similar request (including a patch) was posted to the upstream mailing-list in 2010: https://lists.gnu.org/archive/html/coreutils/2010-12/msg00032.html ... and this was the solution suggested by upstream: https://lists.gnu.org/archive/html/coreutils/2010-12/msg00036.html Ugh. That makes me very sad. Of course that does not solve neither extraneous output (missing is not FAILED): $ sha256sum -c *SUM 2>/dev/null Fedora-Live-Cinnamon-x86_64-23-10.iso: FAILED open or read Fedora-Live-KDE-x86_64-23-10.iso: OK Fedora-Live-LXDE-x86_64-23-10.iso: FAILED open or read Fedora-Live-MATE_Compiz-x86_64-23-10.iso: FAILED open or read Fedora-Live-SoaS-x86_64-23-10.iso: FAILED open or read Fedora-Live-Xfce-x86_64-23-10.iso: FAILED open or read Fedora-Server-DVD-x86_64-23.iso: OK Fedora-Server-netinst-x86_64-23.iso: OK Fedora-Workstation-netinst-x86_64-23.iso: OK Fedora-Live-Workstation-x86_64-23-10.iso: OK nor the exit code. Is there any chance some developer watching RH Bugzilla could pick this up, or is the only reasonable approach here to contact coreutils upstream mailing list? (In reply to Kamil Páral from comment #2) > nor the exit code. You can get the exit code from grep, too, if this is intended for scripting. > Is there any chance some developer watching RH Bugzilla could pick this up, > or is the only reasonable approach here to contact coreutils upstream > mailing list? Upstream ML is definitely a better place for requesting new features unless they are related to downstream patches (which this one is certainly not). Thanks for info. I wanted to avoid mailing lists, that's why I put it here as my first option. Closing, will consider reporting upstream. One reason we _might_ consider this is because currently open() and read() errors are not distinguished. You would want to treat a read() error like a checksum error, and not like an open()==ENOENT. Also other errors from open() should not be treated like ENOENT. Another reason is because grep -E '(OK|FAILED)$' is locale dependent, so one would need LC_ALL=C md5sum ... | grep ... I was 50:50 before, but with the above arguments I'm 60:40 for adding the option. I'll propose upstream. Thanks Pádraig. While working around the problem with grep is possible, it is a) complicated, especially when considering all the corner cases b) not reliable, unless you know exactly what strings *sum tools generate to the output (i.e. you would need to study the source code). Moreover stdout/stderr is not like an API which is guaranteed not to change, your workaround script can break any time. Grep is useful for many things, but modifying program behavior considerably based on stdout/stderr and adjusting exit codes is, I believe, not one of them. Having a specific option to distinguish missing files from unreadable files and invalid checksum files would make everything much easier here. |