Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #16388

Re: hash -l with empty hash table prints to stdout

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>

Show all headers | View raw


[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


Thread

Re: hash -l with empty hash table prints to stdout Eli Schwartz <eschwartz@archlinux.org> - 2020-06-16 10:26 -0400

csiph-web