Bug 232761

Summary: -m options broken
Product: [Fedora] Fedora Reporter: Enrico Scholz <rh-bugzilla>
Component: desktop-file-utilsAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideKeywords: Reopened
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-16 01:28:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Enrico Scholz 2007-03-17 11:10:02 UTC
[I could not find an upstream bugreport address in the package; therefore,
 I report it here]

Description of problem:

The short '-m' option seems to be broken:

| $ desktop-file-install --vendor fedora -m644 --delete-original --dir /var/tmp/distcc-2.18.3-2.fc7-root/usr/share/applications /var/tmp/distcc-2.18.3-2.fc7-root/usr/share/distcc/distccmon-gnome.desktop
| Unknown option ""

When using '--mode 644' or when using desktop-file-utils-0.10 from
FC6, things are fine. Help lists '-m' as a valid option (although it
is completely unclear how the mode can be specified):

| $ desktop-file-install --help-all
| -m, --mode                      Set the given permissions on the destination file.


Version-Release number of selected component (if applicable):

desktop-file-utils-0.12-4


How reproducible:

100%

Comment 1 Matthias Clasen 2007-03-24 17:01:52 UTC
Did you try -m 644 ? (note the space...)

Comment 2 Ray Strode [halfline] 2007-08-14 15:45:35 UTC
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there haven't been any
updates to the report in quite a long time now after we've
requested additional information, we're assuming the problem
is either no longer present in our current OS release, or
that there is no longer any interest in tracking the problem.

Setting status to CANTFIX, however if you still
experience this problem after updating to our latest Fedora
Core release and are still interested in Red Hat tracking
the issue, and assisting in troubleshooting the problem,
please feel free to provide the information requested above,
and reopen the report.

Thank you in advance.

(this message is mass message)

Comment 3 Enrico Scholz 2007-08-15 15:30:46 UTC
happens both with and without space. But space is not needed for options which
require an argument.

Comment 4 Matthias Clasen 2007-08-16 00:50:41 UTC
> But space is not needed for options which require an argument.

What makes you think so ? The GOption parser, which desktop-file-install
uses, supports -m arg or --mode arg or --mode=arg. It also supports -mnop
if m, n, o, p are all accepted short options. 

That being said, the way the --mode support is implemented in desktop-file-install
is buggy and does in fact not work for the short form.

Comment 5 Matthias Clasen 2007-08-16 01:28:32 UTC
Fixed in 0.13-3.fc8

Comment 6 Enrico Scholz 2007-08-16 08:06:30 UTC
>> But space is not needed for options which require an argument.
> What makes you think so ?

More than 10 years of experience with POSIX compliant systems. See
  http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02

point c) which requires that POSIX utils accept both '-m<mode>' and '-m <mode>'
when '-m' requires an argument. As Gnome runs on a POSIX system, I expect that
it follows the rules there.


> The GOption parser, which desktop-file-install uses, supports -m arg 
> or --mode arg or --mode=arg. 

From where do you have this information? My 'desktop-file-install' tells only a
meaningless

|  -m, --mode           Set the given permissions on the destination file.

without specifying how the mode is to be given.


| It also supports -mnop if m, n, o, p are all accepted short options. 

I really in doubt about this because 'nop' is not a valid mode (or Gnome is
missing input validating and converts this to '0').