Re: hash -l with empty hash table prints to stdout
> On Jun 16, 2020, at 10:51 AM, Chet Ramey > wrote: > >> On 6/16/20 10:26 AM, Eli Schwartz wrote: >> >>> 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? > > No, not at all. What are you trying to debug? > > Maybe it would be better to remove the message entirely and only > display it in compatibility mode. The user-friendly way to view the table is by running `hash` without arguments. It prints "hash table empty" as well, which makes sense in that context. Given that, it makes sense to me to change `hash -l`, which is expressly intended for scripting use, to output nothing when the table is empty. vq
Re: hash -l with empty hash table prints to stdout
On 6/16/20 11:07 PM, bel...@web.de wrote: > `shopt' doesn't appear to have an option for giving output re-usable as > input (?). `shopt -p`, surely. Or `shopt -o -p`. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: hash -l with empty hash table prints to stdout
> You might want to temporarily enable posix mode, which suppresses the > message. Good to know. For scripts intended to be sourced, this would include testing for posix mode first, then enable posix mode, run `hash -l', then maybe re- disable it, but ok. Maybe adopt the POSIX-mode behaviour? Does the user need this message at all? > Maybe you could make the empty message be a comment? > > $ hash -l > # hash: hash table empty That, too, would be totally acceptable IMO, and be somewhat analogous to `bind -p'. Another solution might be to only print a message if stdout is a terminal. That sounds slightly horrifying to me, though probably would do "the right thing" in pretty much every situation, I guess. I looked for the pattern "re-?us" in the `help ' outputs and the bash man page to find builtins where similar questions arise and found `alias -p', `bind -X', and `complete' (likewise, `complete -p') which all do not output anything in comparable situations, indicating success. (If `alias -p' gave output "There are no aliases" if there are none, that'd be comparable to the `hash -l' situation, IMO, etc). I didn't manage to make the output of `bind -p', `bind -v', `readonly -p', `set' and `umask -p' logically empty (maybe there are compile-time configurations or setups/systems making this possible). `shopt' doesn't appear to have an option for giving output re-usable as input (?). The output of `enable -p' is logically non-empty as long as there is anything enabled, and I don't know if there's some hackery to access the enable builtin after having disabled it (`enable -n enable' is a dead-end, I think), so the question of whether to output an explanatory message about an otherwise empty output probably doesn't arise here, too.
Re: hash -l with empty hash table prints to stdout
On 6/16/20 10:13 PM, Dale R. Worley wrote: > What a weird problem! Yes, "hash -l" should produce output that can be > read by bash. But sending the "bash: hash table empty" message to > stderr put you in the situation where "hash -l >file" doesn't really > leave the output of "hash -l" in "file". Of course it would. The output of hash -l would be "bash-parseable code to recreate the hash table", as in fact is currently documented. And *diagnostic* messages are not output, and should not be treated as output, and don't belong in that file one way or another. If one really, truly wanted to collect both the expected output *and* the diagnostic messages, one could redirect stderr too... but I don't foresee this as being a problem. ;) People would be more likely to redirect it to /dev/null. > Maybe you could make the empty > message be a comment? > > $ hash -l > # hash: hash table empty > > That is acceptable input for bash, has the right effect when read by > bash, is human-readable, and is capturable by redirecting stdout. As I suggested, yes. :) -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: hash -l with empty hash table prints to stdout
What a weird problem! Yes, "hash -l" should produce output that can be read by bash. But sending the "bash: hash table empty" message to stderr put you in the situation where "hash -l >file" doesn't really leave the output of "hash -l" in "file". Maybe you could make the empty message be a comment? $ hash -l # hash: hash table empty That is acceptable input for bash, has the right effect when read by bash, is human-readable, and is capturable by redirecting stdout. Dale
Re: hash -l with empty hash table prints to stdout
On 6/16/20 10:26 AM, Eli Schwartz wrote: > 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? No, not at all. What are you trying to debug? Maybe it would be better to remove the message entirely and only display it in compatibility mode. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: hash -l with empty hash table prints to stdout
On 6/16/20 9:46 AM, Eli Schwartz wrote: > On 6/16/20 9:30 AM, Chet Ramey wrote: >> On 6/15/20 4:47 PM, bel...@web.de wrote: >> >>> Bash Version: 5.0 >>> Patch Level: 3 >>> Release Status: release >>> >>> Description: >> >>> `hash -l' is supposed to generate output that is reusable as input >>> (`help hash' says so, at least). In case the hash table is empty, a >>> string not re-usable as input is output to stdout. The exit code >>> indicates success in this case. The string being output is locale- >>> dependant (and therefore is hard to filter out in a work-around). >> >> It's an interesting question. An empty hash table is not an error >> condition, and doesn't result in a non-zero exit status, so output to >> stderr is not appropriate. You might want to temporarily enable posix mode, >> which suppresses the message. > > stderr is also a reasonably appropriate place to emit debug info or > warnings. I would consider this a warning condition... It's not a warning; there's nothing to warn about. An empty hash table is not an exceptional condition. It's simply informational. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: hash -l with empty hash table prints to stdout
On 6/16/20 9:30 AM, Chet Ramey wrote: > On 6/15/20 4:47 PM, bel...@web.de wrote: > >> Bash Version: 5.0 >> Patch Level: 3 >> Release Status: release >> >> Description: > >> `hash -l' is supposed to generate output that is reusable as input >> (`help hash' says so, at least). In case the hash table is empty, a >> string not re-usable as input is output to stdout. The exit code >> indicates success in this case. The string being output is locale- >> dependant (and therefore is hard to filter out in a work-around). > > It's an interesting question. An empty hash table is not an error > condition, and doesn't result in a non-zero exit status, so output to > stderr is not appropriate. You might want to temporarily enable posix mode, > which suppresses the message. stderr is also a reasonably appropriate place to emit debug info or warnings. I would consider this a warning condition... -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: hash -l with empty hash table prints to stdout
On 6/15/20 4:47 PM, bel...@web.de wrote: > Bash Version: 5.0 > Patch Level: 3 > Release Status: release > > Description: > `hash -l' is supposed to generate output that is reusable as input > (`help hash' says so, at least). In case the hash table is empty, a > string not re-usable as input is output to stdout. The exit code > indicates success in this case. The string being output is locale- > dependant (and therefore is hard to filter out in a work-around). It's an interesting question. An empty hash table is not an error condition, and doesn't result in a non-zero exit status, so output to stderr is not appropriate. You might want to temporarily enable posix mode, which suppresses the message. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
