Received-SPF: pass (google.com: domain of netbsdrat AT gmail DOT com designates 10.52.179.10 as permitted sender) client-ip=10.52.179.10;
MIME-Version: 1.0
Date: Wed, 29 Feb 2012 16:21:43 -0800
Message-ID: <CAB3JEf9NG6n3xpaJy=tudYz6=b7knwB9jHVJHkB6zqULHmXMUw@mail.gmail.com>
Subject: Mostly fixed issue with pathnames from windows, a few cases to go...
From: John Refling <netbsdrat AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=ISO-8859-1
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

In a recent cygwin update (from cygwin-1.7.10-1), the issues that I
reported in the
following link:

http://cygwin.com/ml/cygwin/2012-01/msg00373.html

``Problems with UNC filenames passed to bash when called from a
windows shortcut,''
have been mostly corrected.  The issue was the incorrect processing of
some windows
generated pathnames in certain cases.  There are still a few cases that need
fixing as of 29 Feb 2012 (cygwin-1.7.11-1).

To recap, I discovered the issue when calling bash via windows XP by selecting
files with the mouse and dropping them on a bash shortcut which called a shell
script, expecting the filenames to be passed to the shell script.  This
happened, except some of the filenames the script received were mangled.

The filenames were mangled when the dragged file was on a network share and had
a space in it (e.g. "\\fileshare\file name") and a few other cases with
special characters such '()[{}.  Previous discussion indicated that the
problem might have been a correct consequence of bash processing the quoted
backslash "\\" and the other special pattern matching, and expansion characters
in bash variables before being passed to the shell script.

I have since determined that it is not a bash issue as it affects dragging and
dropping filenames onto any cygwin/gcc compiled executable (bash being one).
This case is easier to explain than the bash case,  and does not (or should not)
involve any backslash/expansion issues since bash is not involved.

The following program when compiled under cygwin/gcc experienced the mangling
of some network filenames as evidenced by the filenames failing the stat():

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/stat.h>
int main(int argc, char **argv) {
    argc--; argv++;
    struct stat mystat;
    while (argc > 0) {
        if (-1 == stat(*argv, &mystat)) {
            printf("MANGLED: %s\n", *argv);
        } else {
            printf("OK FILE: %s\n", *argv);
        }
        argc--; argv++;
    }
    printf("Press enter...");
    getc(stdin);
    return 0;
}

The same program compiled with tcc (tiny c) does not have this problem when
network files are dragged and dropped on it.

A few weeks ago (before a recent cygwin update), the following types of
network filenames became mangled (they also have a \\ in in):

1) any filename with a space in it (windows quotes it to "\\share\file name"
2) any filename with a '()[{} space or not (quoted or unquoted)

After the recent update, most cases have been fixed, however the following
network filenames (with \\ in them) are still mangled:

1) any filename with a ' in it and NO space in it,
   e.g. \\share\file'name becomes \\share\filename and stat() fails.
2) any filename with a { in it and NO space in it,
   e.g. \\share\file{name becomes \\share\file and stat() fails.

It still seems that some sort of variable expansion a la bash is happening
at the lowest level of parameter assignment to executables, where it should
not happen.

Thanks for fixing most of the issues, as far as I can tell, these are the last
of the cases that need to be fixed.


John Refling

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple