Please don’t make the behavior of a utility depend on the name used to invoke it. It is useful sometimes to make a link to a utility with a different name, and that should not change what it does.
Instead, use a run time option or a compilation switch or both to select among the alternate behaviors. You can also build two versions of the program, with different names and different default behaviors.
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
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
ls except that its default output format is always