#1619 MSYS: mkdir (coreutils-5.97) mishandles -- argument

MSYS
closed
None
Bug
none
Unreproducible
False
2013-02-09
2012-01-16
No

Command:

$ mkdir -p -- ../foo/bar
mkdir: ambiguous long option '--'

This is with mkdir from the current MSYS release of coreutils. The intent of the '--' argument is to indicate that no further option arguments follow, even if some exhibit a format which would normally cause them to be interpreted as such; POSIX advocates this interpretation: http://pubs.opengroup.org/onlinepubs/009604499/basedefs/xbd_chap12.html (guideline 10).

I don't know if this bug is an artefact of the particular version of coreutils used by MSYS, or is specific to the MSYS build itself; it certainly isn't evident in the coreutils-8.5 build on my GNU/Linux box.

Current CVS of GNU Troff gratuitously assumes that mkdir handles this syntax correctly. Thus, building from this source fails on MSYS. I'll also report this to bug-groff, with reference to this ticket.

Discussion

  • Earnie Boyd

    Earnie Boyd - 2012-01-16

    I'm not seeing this with:

    $ mkdir --version
    mkdir (GNU coreutils) 5.97
    Copyright (C) 2006 Free Software Foundation, Inc.
    This is free software. You may redistribute copies of it under the terms of
    the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
    There is NO WARRANTY, to the extent permitted by law.

    Written by David MacKenzie.

     
  • Keith Marshall

    Keith Marshall - 2012-01-17

    Curious. Do you mean that 'mkdir --version' works, or that 'mkdir -p -- ../foo/bar' works for you?

    The bug isn't that long options, in general, don't work; rather, it is specifically that stand-alone '--' isn't correctly interpreted as an options terminator:

    $ mingw-get update
    Update catalogue: package-list.xml
    ...
    Update catalogue: msys-package-list.xml
    ...
    Update catalogue: msys-coreutils.xml
    ...

    $ rm /var/cache/mingw-get/packages/*coreutils*

    $ mingw-get install --reinstall msys-coreutils-bin
    http://prdownloads.sourceforge.net/mingw/coreutils-5.97-3-msys-1.0.13-bin.tar.lzma?download
    288.85 kB / 288.85 kB |================================================| 100%
    install: coreutils-5.97-3-msys-1.0.13-bin.tar.lzma
    installing coreutils-5.97-3-msys-1.0.13-bin.tar.lzma

    $ which mkdir
    /bin/mkdir

    $ mkdir --version
    mkdir (GNU coreutils) 5.97
    Copyright (C) 2006 Free Software Foundation, Inc.
    This is free software. You may redistribute copies of it under the terms of
    the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
    There is NO WARRANTY, to the extent permitted by law.

    Written by David MacKenzie.

    $ mkdir -p -- foo/bar
    mkdir: ambiguous long option '--'

    $ msysinfo -all > msysinfo.all

    $ cat <<\EOF> session.txt
    > ...
    > EOF

     
  • Keith Marshall

    Keith Marshall - 2012-01-17

    full log of session in comment #2

     
  • Keith Marshall

    Keith Marshall - 2012-01-17

    output from 'msysinfo all' -- sensitive data elided

     
  • Fredric

    Fredric - 2012-01-17

    mkdir -p -- ../foo/bar
    works fine here too

     
  • Earnie Boyd

    Earnie Boyd - 2012-01-17

    I mean that mkdir -p -- ../foo/bar works for me.

    I'm not seeing the ambiguous long option error.

    msysinfo -all > msysinfo.all

     
  • Earnie Boyd

    Earnie Boyd - 2012-01-17
     
  • Keith Marshall

    Keith Marshall - 2012-02-01

    Hmm. There's clearly something messed up in my installation. The problem is completely reproducible, when running the primary MSYS installation, but not when running a secondary installation, (of the same components/versions), from a USB thumb drive, (on the same host).

    Forcing a reinstall, (with mingw-get install --reinstall), of the msys-core and msys-coreutils-bin components DOESN'T correct the problem.

    Moving the MSYS bin, etc, include, lib, libexec, postinstall, sbin, and spool directories out of the way, removing all of mingw-get's installation manifest files with references to the MSYS sysroot record file, and that sysroot record file itself, followed by a fresh mingw-get install of just msys-base, (into the original sysroot path), DOES correct the problem, but obviously leaves me with fewer installed components than I had previously.

    For now, I'll leave this open at minimum priority. As time permits, I'll start adding components one at a time, until I've replaced everything I had installed previously. If, on the way, I manage to reproduce the problem, I'll post details of the offending component; if I get back to my original inventory, without recurrence of the problem, I'll close this as "not reproducible".

     
  • Keith Marshall

    Keith Marshall - 2012-02-01
    • milestone: --> Waiting_User_Response
    • priority: 5 --> 1
     
  • Keith Marshall

    Keith Marshall - 2012-02-01

    For clarification: while having the same components/versions as the primary installation, the USB thumb drive had only a subset of the full component inventory of the primary installation.

     
  • Earnie Boyd

    Earnie Boyd - 2013-01-21
    • resolution: --> none
    • category: --> Waiting_User_Response
    • milestone: Waiting_User_Response --> MSYS
     
  • Earnie Boyd

    Earnie Boyd - 2013-02-08
    • labels: MSYS -->
    • status: open --> pending
    • type: --> Bug
    • patch_attached: --> False
     
  • Earnie Boyd

    Earnie Boyd - 2013-02-08

    Keith, any follow-up with this

     
  • Keith Marshall

    Keith Marshall - 2013-02-09

    Corporate IT swapped out my PC, shortly after this arose. I've not noticed it on the new one, (although I've not explicitly tested). May as well close, I think; if the issue recurs, I'll open a new ticket.

     
  • Keith Marshall

    Keith Marshall - 2013-02-09
    • status: pending --> closed
    • category: Waiting_User_Response --> Unreproducible
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks