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