Why do many commands provide a "quiet" option?

Question

Why do many commands provide the option -q or --quiet to suppress output when you can easily achieve the same thing by redirecting standard output to the null file?

Not all commands use -q to suppress all output. For example, Docker has a command to list images; docker images shows a formatted table with a bunch of information, while docker images -q outputs a plain list of image IDs (useful for piping to other commands). — new123456, Mar 19 '15 at 20:42

score 75 · Accepted Answer · edited Mar 20 '15 at 20:18

75

While you can easily redirect in a shell, there are other contexts where it's not as easy, like when executing the command in another language without using a shell command-line. Even in a shell:
```
find . -type f -exec grep -q foo {} \; -printf '%s\n'
```
to print the size of all the files that contain foo. If you redirect to /dev/null, you lose both find and grep output. You'd need to resort to -exec sh -c 'exec grep foo "$1" > /dev/null' sh {} \; (that is, spawn an extra shell).
grep -q foo is shorter to type than grep foo > /dev/null
Redirecting to /dev/null means the output is still written and then discarded, that's less efficient than not writing it (and not allocate, prepare that output to be written)
that allows further optimisations. In the case of grep for instance, since with -q, grep knows the output is not required, it exits as soon as it finds the first match. With grep > /dev/null, it would still try to find all the matches.
quiet doesn't necessarily mean silent. For some commands, it means reduce verbosity (the opposite of -v|--verbose). For instance, mplayer has a --quiet and a --really-quiet. With some commands, you can use -qqq to decrease verbosity 3 times.

edited Mar 20 '15 at 20:18

mikeserv

58,310

answered Mar 19 '15 at 16:57

Stéphane Chazelas

544,893

It's noteworthy that in the grep man-page both options, -q, and -s, are suggested to be avoided if portability is a concern. grep's early exit is an important optimization, but not all programs with such options can do that; curl -s will still process the whole data (but the 3rd point still applies, thus saving processing time). – Janis Mar 19 '15 at 17:12
6

@Janis, that would be portability to very old systems. Both -q and -s are specified by POSIX. If we're to consider systems that old, then my sh -c '...' sh {} \; won't work either (with earlier ksh-based shs). – Stéphane Chazelas Mar 19 '15 at 17:17
The man page mentions: USG-style grep also lacked -q but its -s option behaved like GNU grep. - I thought that the difference in behaviour could be an issue. I can't judge about its relevance. – Janis Mar 19 '15 at 17:31
I frequently use the -q and --quiet options when I only care about the return code of a command in a script. The reasons noted above are even better examples why. – Mark Stewart Mar 19 '15 at 17:57
@StéphaneChazelas: you'd be amazed how (parts of) many systems are still that old... (well, actually, not that many ^^ but there are still some) – Olivier Dulac Mar 19 '15 at 18:28
1

@Janis - it may be that the GNU grep manpage warning of -q portability concerns has another implication. Some readings of POSIX grep pages, when considered alongside Utility Description Defaults might imply that { grep -q pattern; head; } <seekable_file would print only the 10 lines following the first match for pattern. GNU grep won't do that (not even when combined with its non-POSIX -m1). – mikeserv Mar 20 '15 at 14:45
mikeserv, is that a typo in your comment (using a semicolon instead of pipe inbetween the two processes)? – Janis Mar 20 '15 at 16:02
@Janis, no he's refering to { sed -n 2q; head -n 1; } < seekable_file that should return the 3rd line as per POSIX (GNU sed doesn't), that is that sed should leave the cursor position just after the 2nd line. However, there's not such requirement for grep -q as POSIX doesn't mandate grep exits upon processing the first matching line. – Stéphane Chazelas Mar 20 '15 at 16:04
Stéphane and @Janis - it isn't mandated that it exit, but the Informative section of the grep spec says it can - and I assume that is because many do - though I don't know of any. The Utility Defaults says that all standard utilities should leave the offset immediately following the last byte read when through. But the weird part about GNU grep -q is grep -qm1 - where, for whatever reason, though they spec -m1 to leave the offset after the matching line, adding the -q nullifies this. – mikeserv Mar 20 '15 at 20:06
And actually, Stéphane, I don't know. The grep -q verbiage (Quiet... Exit with zero status if an input line is selected) doesn't differ terribly from sed q (Branch to the end of the script and quit without starting a new cycle). When taken in context with mandated exit offset behavior (When a standard utility reads a seekable input file and terminates without an error before it reaches end-of-file, the utility shall ensure that the file offset in the open file description is properly positioned just past the last byte processed by the utility) I should think they'd behave similarly. – mikeserv Mar 20 '15 at 20:43
And curl has to receive the remainder of the stream for error detection reasons. – waltinator Apr 02 '22 at 01:03

score 3 · Answer 2 · answered Mar 19 '15 at 16:49

3

It still allows for the command to put out when It feels it needs to a note to the screen but normally it puts nothing out. with redirecting all to null there is no chance for the output to be seen.

answered Mar 19 '15 at 16:49

LhasaDad

141

Well, quiet means that no response is expected; it would be unexpected if we'd see output anyway. (In case that there's anyway something "really really really" important to print (in a terminal attached process) a tty/pty device could directly be used by the process. An example for that may be interactive inquiry of a password, or somesuch.) – Janis Mar 19 '15 at 16:57

score 2 · Answer 3 · answered Mar 19 '15 at 17:16

Although it probably depends on the command, -q would also disable output to stderr. This allows shells that don't easily allow duping stderr to stdout (I'm looking at you, csh & tcsh) to avoid the noise.

Some programs provide a "quiet" option for situations where it may have other meaningful output that you don't want cluttered with status messages. The -q or equivalent would silence all program status output, allowing a pure data stream from, say, tar or gzip.

score 0 · Answer 4 · edited Apr 01 '22 at 17:06

Besides all the good responses and points above, it is a best practice to provide an opposite option for every flag. So, if there is -v for verbosity there should be -q for non-verbosity, quiet or silence. (This is not the point of discussion though...) There should be a long option for every short one as well, -q and --quiet.

As in almost everything in our business, there are many ways to get a solution or the same results. Having -q is one of them.

Why do many commands provide a "quiet" option?

4 Answers4