`mount` command and POSIX Utility Syntax Guidelines

`mount` command and POSIX Utility Syntax Guidelines

[Timothy Madden]

Hello,

I have the little annoying problem that I can not mount a DAV folder 
with the davfs2 filesystem, because I usually keep POSIXLY_CORRECT 
environment variable set. The var allows me to keep an "aliases" file 
(similar to ~/.basrc) and change it when needed if I put the file name 
in the ENV variable.

The problem is with the invocation of the mount helper command. `mount` 
will compose a command line like this:
    /sbin/mount.davfs \
           https://storage-file-eu.gmx.com/ \
           ./gmx-file-storage \
           -o rw,nosuid,nodev,noauto,user,_netdev,exec
where the option arguments ("-o rw,...") follow the operands (device, 
mount point) on the command line.

However GNU getopts() (from glibc) follows POSIX Utility Syntax 
Guidelines in this case and expects the option arguments before the 
operands.

Subsequently the mount command returns and error when mounting my DAV
folders. I am currently using a wrapper executable around mount.davfs 
that changes the order of arguments on the command line to make it work.

I hope mount command composes such a command line for historical reasons 
and that there are no hidden problems with the order of the options on 
the command line for mount helpers.

Is it please possible for mount command to be updated to change the 
order of arguments on the command line, so that it follows the POSIX 
guidelines ? At least when POSIXLY_CORRECT is set in the environment ?

I have "mount from util-linux 2.21.2 (with libblkid support)" on 
Slackware 13.37 32-bit updated with Slackware-current packages. Also 
happens on up-to-date CentOS 6.3 64-bit with updates from centosplus 
repository, that is "mount from util-linux-ng 2.17.2 (with libblkid and 
selinux support)".


See also the mount.davfs issue report at
      http://savannah.nongnu.org/support/?108145
or the issue reported on Slackware list at:
      http://comments.gmane.org/gmane.linux.slackware/4084

Thank you,
Timothy Madden

Re: `mount` command and POSIX Utility Syntax Guidelines

[Karel Zak]

On Wed, Oct 10, 2012 at 02:28:06AM +0300, Timothy Madden wrote:
> I have the little annoying problem that I can not mount a DAV folder with
> the davfs2 filesystem, because I usually keep POSIXLY_CORRECT environment
> variable set. The var allows me to keep an "aliases" file (similar to
> ~/.basrc) and change it when needed if I put the file name in the ENV
> variable.

 Well, from my point of view is it mistake that getopt() supports
 something like $POSIXLY_CORRECT. It's application, not library, who
 has to control input/command line parsing.

 The shared libraries should be sensitive only to environment
 variables which control library private stuff or things which are
 really transparent to applications (LANG=...).

> Is it please possible for mount command to be updated to change the order of
> arguments on the command line, so that it follows the POSIX guidelines?

 The mount helpers command line is out documented API. I don't see a
 way how to change it without break the compatibility between mount(8)
 and mount.<type> helpers.

> At least when POSIXLY_CORRECT is set in the environment ?

 Don't assume that everyone uses getopt() from glibc. You can
 use "if (strcmp(argv[], ...))" to parse command line arguments.

 I think it would be better to remove POSIXLY_CORRECT from
 mount.<type> environment in mount(8) before we execute the helper.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: `mount` command and POSIX Utility Syntax Guidelines

[Timothy Madden]

On 10/10/2012 11:36 AM, Karel Zak wrote:
> On Wed, Oct 10, 2012 at 02:28:06AM +0300, Timothy Madden wrote:
>> I have the little annoying problem that I can not mount a DAV folder with
>> the davfs2 filesystem, because I usually keep POSIXLY_CORRECT environment
>> variable set. The var allows me to keep an "aliases" file (similar to
>> ~/.basrc) and change it when needed if I put the file name in the ENV
>> variable.
>
>   Well, from my point of view is it mistake that getopt() supports
>   something like $POSIXLY_CORRECT. It's application, not library, who
>   has to control input/command line parsing.
[...]
>> Is it please possible for mount command to be updated to change the order of
>> arguments on the command line, so that it follows the POSIX guidelines?
>
>   The mount helpers command line is out documented API. I don't see a
>   way how to change it without break the compatibility between mount(8)
>   and mount.<type> helpers.
>
>> At least when POSIXLY_CORRECT is set in the environment ?
>
>   Don't assume that everyone uses getopt() from glibc. You can
>   use "if (strcmp(argv[], ...))" to parse command line arguments.
>
>   I think it would be better to remove POSIXLY_CORRECT from
>   mount.<type> environment in mount(8) before we execute the helper.

Maybe the mount helpers should follow POSIX guidelines, too.

Of the helpers that I have installed on my two systems (Slackware and 
CentOS), namely cifs, davfs, nfs/nfs4, ntfs/ntfs-3g/lowntfs-3g, it is 
only nfs that does indeed complain about syntax if I try to pass the 
options first and the operands next on the command line. Both my systems 
have "mount.nfs (linux nfs-utils 1.2.3)".

Maybe they can change the expected order for command line arguments (in 
the linux nfs-utils project), together with changes in mount, or before 
changes in mount (to be safe).

If anyone knows other mount helpers I should check for command line 
syntax, please jump in and add to the list.

Even without using GNU getopts(), I believe POSIX guidelines should 
still be taken into account, no matter how the command line is parsed or 
what library (or application) is used.

About removing POSIXLY_CORRECT before the mount helper is invoked, I 
would not easily take that path. I believe POSIXLY_CORRECT is a /user/ 
setting, with specific side-effects, and a such system command should 
not implicitly change it, without prior consent from the user. That is, 
the user might wonder why his mount helper, that he is working so hard 
on, does not receive the environment the user prepared for it and expects.

Thank you,
Timothy Madden