Bug 183032 - gnome-mount spills garbage on stdout
gnome-mount spills garbage on stdout
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: gnome-mount (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: John (J5) Palmieri
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-25 12:39 EST by Michal Jaegermann
Modified: 2013-03-13 00:49 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-27 14:30:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2006-02-25 12:39:27 EST
Description of problem:

After an update to gnome-mount-0.4-2 every invocation of 'gnome-mount',
with an exception of 'gnome-mount --help' where this would be understandable,
prints on stdout "gnome-mount 0.4"

Version-Release number of selected component (if applicable):
gnome-mount-0.4-2

How reproducible:
always unless '--help' or other of help options is given
Comment 1 John (J5) Palmieri 2006-02-27 11:08:18 EST
Is this an issue?  We perhaps should have a verbose option for this but does it
cause any real issues right now?
Comment 2 David Zeuthen 2006-02-27 11:11:59 EST
Why is this a problem?
Comment 3 Michal Jaegermann 2006-02-27 12:47:06 EST
> Why is this a problem?

The problem is that Unix/Linux programs should not produce a spurious
output, i.e. without asking, and especially when this happens on
stdout.  stderr is somewhat looser in this respect.  You have no idea
how and where this will be used and what will have to parse that. One
or two such "weirdos" is not a big deal but if they will start to
multiply you will have a huge mess on hands in no time at all.  It
would be perhaps a different story if something would really need such
strings, although at a minimum a flag to shut that up would be
advisable, but this does not look like the case.

It is somewhat strange that such things require explanations.
Comment 4 John (J5) Palmieri 2006-02-27 13:06:37 EST
We are in a deep freeze right now.  The purpose of the questions was to assess
how much of a problem this is.  Since it does not produce any adverse effects
and is more of a purity issue, I'm not going to make this a Blocker or even a
Target bug and will assume it will be fixed upstream and make it into a future
release.  
Comment 5 David Zeuthen 2006-02-27 13:11:50 EST
> The problem is that Unix/Linux programs should not produce a spurious
> output, i.e. without asking, and especially when this happens on
> stdout.  stderr is somewhat looser in this respect.

This Unix/Linux mentality of "error checking" is just broken. Didn't you get the
memo?

> It is somewhat strange that such things require explanations.

Being rude is a great way to get your wish implemented.
Comment 6 Michal Jaegermann 2006-02-27 13:48:57 EST
> We are in a deep freeze right now. 

Well, this extra junk showed up during that "deep freeze".  But in particular
I had to replace /usr/bin/eject with a script which is using 'gnome-umount'.
Now this script requires extra handling.
Comment 7 John (J5) Palmieri 2006-02-27 14:30:07 EST
For Comment #6 - those issues were fixed awhile back.  Can't help you if you try
to work around bugs on a test distro.  Clearly you care about how this all works
so I suggest you get involved upstream and start sending patches and reading the
hal-devel list as most of these issues are found and fixed in due time.

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