RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.0
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
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
Environment:
Last Closed: 2016-01-07 21:47:29 UTC
Target Upstream Version:
Embargoed:

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

docker-1.0.0-10.el7.x86_64
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.

https://github.com/docker/docker/pull/9085

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.