Bug 232761 - -m options broken
Summary: -m options broken
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: desktop-file-utils
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-17 11:10 UTC by Enrico Scholz
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-08-16 01:28:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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').



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