4 ms·

Looks over at the Nix tools that just added a bunch of success messages because users found silence confusing

by 3836293648 5y ago

forty 5y ago
Maybe a good middle ground would be to use isatty to check if you should display something or not?
- enriquto 5y ago
  No. That would be confusing. Silent success is a basic tenet of unix and must not be relinquished.
- teddyh 5y ago
  The GNU Coding Standards recommends not doing that: “Likewise, please don’t make the behavior of a command-line program depend on the type of output device it gets as standard output or standard input. Device independence is an important principle of the system’s design; do not compromise it merely to save someone from typing an option now and then. (Variation in error message syntax when using a terminal is ok, because that is a side issue that people do not depend on.) If you think one behavior is most useful when the output is to a terminal, and another is most useful when the output is a file or a pipe, then it is usually best to make the default behavior the one that is useful with output to a terminal, and have an option for the other behavior. You can also build two different versions of the program with different names. There is an exception for programs whose output in certain cases is binary data. Sending such output to a terminal is useless and can cause trouble. If such a program normally sends its output to stdout, it should detect, in these cases, when the output is a terminal and give an error message instead. The -f option should override this exception, thus permitting the output to go to the terminal. Compatibility requires certain programs to depend on the type of output device. It would be disastrous if ls or sh did not do so in the way all users expect. In some of these cases, we supplement the program with a preferred alternate version that does not depend on the output device type. For example, we provide a dir program much like ls except that its default output format is always multi-column format.” — https://www.gnu.org/prep/standards/standards.html#User-Interfaces https://www.gnu.org/prep/standards/standards.html#User-Inter...
  - ghostpepper 5y ago
    > You can also build two different versions of the program with different names. Do any programs actually do this? Sounds like the biggest headache of all ls_terminal vs ls_pipeable | grep ...
  - ElevenLathe 5y ago
    Interesting that a major GNU util (ls) does exactly the opposite and prints differently (multiple entries on a line vs one line per entry) in terminal vs a pipe.
    - teddyh 5y ago
      The last paragraph I quoted explicitly mentions ls as doing that for compatibility reasons; i.e. Unix did it that way, and GNU should be compatible.
mplanchard 5y ago
At least they go to stderr I think
- switch007 5y ago
  mail admins must be delighted about that (cron…)

Looks over at the Nix tools that just added a bunch of success messages because users found silence confusing

forty 5y ago

Maybe a good middle ground would be to use isatty to check if you should display something or not?

enriquto 5y ago
No. That would be confusing. Silent success is a basic tenet of unix and must not be relinquished.
teddyh 5y ago
The GNU Coding Standards recommends not doing that: “Likewise, please don’t make the behavior of a command-line program depend on the type of output device it gets as standard output or standard input. Device independence is an important principle of the system’s design; do not compromise it merely to save someone from typing an option now and then. (Variation in error message syntax when using a terminal is ok, because that is a side issue that people do not depend on.) If you think one behavior is most useful when the output is to a terminal, and another is most useful when the output is a file or a pipe, then it is usually best to make the default behavior the one that is useful with output to a terminal, and have an option for the other behavior. You can also build two different versions of the program with different names. There is an exception for programs whose output in certain cases is binary data. Sending such output to a terminal is useless and can cause trouble. If such a program normally sends its output to stdout, it should detect, in these cases, when the output is a terminal and give an error message instead. The -f option should override this exception, thus permitting the output to go to the terminal. Compatibility requires certain programs to depend on the type of output device. It would be disastrous if ls or sh did not do so in the way all users expect. In some of these cases, we supplement the program with a preferred alternate version that does not depend on the output device type. For example, we provide a dir program much like ls except that its default output format is always multi-column format.” — https://www.gnu.org/prep/standards/standards.html#User-Interfaces https://www.gnu.org/prep/standards/standards.html#User-Inter...
- ghostpepper 5y ago
  > You can also build two different versions of the program with different names. Do any programs actually do this? Sounds like the biggest headache of all ls_terminal vs ls_pipeable | grep ...
- ElevenLathe 5y ago
  Interesting that a major GNU util (ls) does exactly the opposite and prints differently (multiple entries on a line vs one line per entry) in terminal vs a pipe.
  - teddyh 5y ago
    The last paragraph I quoted explicitly mentions ls as doing that for compatibility reasons; i.e. Unix did it that way, and GNU should be compatible.

mplanchard 5y ago

At least they go to stderr I think

switch007 5y ago
mail admins must be delighted about that (cron…)