Bug 1121209 - Docker usage does not print to stdout with error on stderr
Summary: Docker usage does not print to stdout with error on stderr
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.0
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: atomic-bugs@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-18 16:05 UTC by Chris Evich
Modified: 2019-03-06 02:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1098280
Last Closed: 2016-01-07 21:47:29 UTC

Attachments (Terms of Use)

Description Chris Evich 2014-07-18 16:05:49 UTC
+++ This bug was initially created as a clone of Bug #1098280 +++

Client version: 1.0.0
Client API version: 1.12
Go version (client): go1.2.2
Git commit (client): 20fdb42/1.0.0
Server version: 1.0.0
Server API version: 1.12
Go version (server): go1.2.2
Git commit (server): 20fdb42/1.0.0

Cloned to address second part of problem from bug 1098280:
Typically usage statements are not considered things that should be printed to errors, only error messages are considered errors.

 ❯ docker attach
                                   <<<<<< no error message to stderr
                                   -------usage below should be stdout
Usage: docker attach [OPTIONS] CONTAINER

Attach to a running container

  --no-stdin=false: Do not attach stdin
  --sig-proxy=true: Proxify all received signal to the process (even in non-tty mode)

Expected results:
Misuse of commands should print out an error to stderr, and the usage to stdout (or don't print usage at all):

 ❯ docker attach
Error: attach requires a container   <<<< printed to stderr
Usage: docker attach [OPTIONS] CONTAINER   <<< printed to stdout

Attach to a running container

  --no-stdin=false    Do not attach stdin
  --sig-proxy=true    Proxify all received signal to the process (even in non-tty mode)

Comment 2 Daniel Walsh 2014-07-18 16:51:46 UTC
I actually like the way git does this better

> git foobar
git: 'foobar' is not a git-command. See 'git --help'.

Just don't print the usage on error.  Since you loose the error message in the noice.

Comment 3 Chris Evich 2014-07-18 20:30:28 UTC
Yep, I agree.  It's a much simpler solution also.

Comment 4 Matthew Heon 2014-07-23 17:20:18 UTC
Moving usage to stderr was a deliberate change, though an older one (made back in 2013 - https://github.com/dotcloud/docker/commit/75a7f4d90cde0295bcfb7213004abce8d4779b75). 

Nearest I can tell, they are actually being consistent with typical program behavior. Git, for example, does print usage information on passing an invalid argument (for example, 'git -adsf add'), and this usage information is printed to stderr. All the commonly-used programs I tried which printed usage information on an argument error printed it to stderr.

Removing usage information from error messages is reasonable, though, given that some commands (docker run, most notably) have grown 40+ line usage messages. I'll send a PR upstream about this.

Comment 5 Chris Evich 2014-07-23 18:14:15 UTC
Thanks matthew, and thanks for the research on other commands that do this.  In that case, if the community says no, it's not that horrible.  It's much more important the behavior is consistent (which we already have).

Comment 6 Daniel Walsh 2014-09-12 19:22:51 UTC
I have this fix in docker-1.2

Comment 7 Chris Evich 2014-10-28 15:55:05 UTC
Tests updated, this one looks good as of 1.3 (didn't check 1.2).

Comment 8 Chris Evich 2014-12-12 20:55:31 UTC
This is regressing in docker-1.3.2-4.el7.x86_64, usage info is once again going to stderr instead of stdout making it impossible to grep.

Tested with: 'docker help run | grep DNS'

Comment 9 Daniel Walsh 2014-12-13 12:46:15 UTC
This has only ever been fixed in our HTB versions which included patches to fix this.

The released version does not carry the patch.  :^(

The patch is currently here.


Add a comment indicating the importance of this patch and maybe it will finally get merged.

Comment 10 Chris Evich 2014-12-15 16:48:24 UTC
Thanks for the insight dan, that explains it perfectly.  Uggg, that stinks about the PR, though recent comments show it seems to be getting some traction.  Either way, I've commented in the upstream PR as suggested, explaining why it's very important to fix this.  Thanks again.

Comment 11 Daniel Walsh 2015-01-19 15:04:31 UTC
Fixed in docker-1.4.1

Note You need to log in before you can comment on or make changes to this bug.