bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: beluro
Subject: Re: hash -l with empty hash table prints to stdout
Date: Wed, 17 Jun 2020 05:07:31 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

> 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 <builtin>' 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]