Bug 232761 - -m options broken
-m options broken
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: desktop-file-utils (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-17 07:10 EDT by Enrico Scholz
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-15 21:28:32 EDT
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 Enrico Scholz 2007-03-17 07:10:02 EDT
[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 13:01:52 EDT
Did you try -m 644 ? (note the space...)
Comment 2 Ray Strode [halfline] 2007-08-14 11:45:35 EDT
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 11:30:46 EDT
happens both with and without space. But space is not needed for options which
require an argument.
Comment 4 Matthias Clasen 2007-08-15 20:50:41 EDT
> 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-15 21:28:32 EDT
Fixed in 0.13-3.fc8
Comment 6 Enrico Scholz 2007-08-16 04:06:30 EDT
>> 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.