Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #16388
| From | Eli Schwartz <eschwartz@archlinux.org> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: hash -l with empty hash table prints to stdout |
| Date | 2020-06-16 10:26 -0400 |
| Message-ID | <mailman.1981.1592317632.2541.bug-bash@gnu.org> (permalink) |
| References | <20200615204717.GB28118@jar> <bd77214b-2690-f5de-a814-108e5be8b6f1@case.edu> <447bbb87-ce9a-e038-5a00-68646f9771c4@archlinux.org> <067bf5a9-72ba-f6f6-a170-d1ebaa54919b@case.edu> <69a0b336-4f2e-3c9f-cacf-79358ed33bf4@archlinux.org> |
[Multipart message — attachments visible in raw view] - view raw
On 6/16/20 9:56 AM, Chet Ramey wrote: > It's not a warning; there's nothing to warn about. An empty hash table is > not an exceptional condition. It's simply informational. Then would you say it is debug info? Why is stderr not a good place for this? hash -l documents that its output may be reused as input, which assumption breaks down if the hash table is empty. If "send the non-eval'able diagnostic output to stderr, separate from the eval'able output stream" isn't a convincing argument to you, then perhaps it could be prefixed with a "#" such that eval'ing it would skip that line? -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User
Back to gnu.bash.bug | Previous | Next | Find similar
Re: hash -l with empty hash table prints to stdout Eli Schwartz <eschwartz@archlinux.org> - 2020-06-16 10:26 -0400
csiph-web