bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new modules 'open', 'fopen', 'freopen'


From: Brian Dessent
Subject: Re: new modules 'open', 'fopen', 'freopen'
Date: Sun, 07 Oct 2007 00:29:00 -0700

Bruno Haible wrote:

> The precise circumstances are not clear to me. When I run, from an rxvt
> running the msys /bin/sh,
> 
>   $ H:/msys/local/bin/msgfmt.exe --statistics /dev/null
> 
> it succeeds. When from this shell, I run "cmd" (the Microsoft command
> interpreter), and from there

Like Eric said, this is because MSYS provides argument conversion when
invoking non-MSYS apps.  You can demonstrate this at the MSYS shell:

$ cmd //c echo /dev/null
nul

Note here that the double slash is necessary to convey to the runtime
that "/c" is a command option and not a POSIX style path that needs
translating.

> Should other Cygwin syntaxes, like "/cygdrive/c/autoexec.bat", be converted
> to native Woe32 syntax as well? Maybe. It has not been reported so far.

I think that would be a very bad idea.  For one thing, "cygdrive" is
just the default name for the prefix, but the user can set it to any
string, including blank.  And this is not the only prefix that might be
encountered, as a default Cygwin install has /usr, /home, /var, /etc and
so on.  Moreover, the mount table can contain arbitrary mappings, for
example I mount c:/Program Files on /pgf as a typing and
whitespace-eliminating shortcut.  So if you wanted to implement this
correctly it would require full parsing of the Cygwin mount table.  I
don't see how special-casing this one prefix really buys anything,
because it feels very hacky especially when the cygpath utility exists
and solves the problem in the right way.

And just a nit:

Eric Blake wrote:
>
> This is because the msys shell is specially compiled with a hack that
> alters command line arguments that look like filenames into their windows
> equivalent, before invoking the child program.  And sometimes this hack
> backfires, when a command line argument is translated even though it
> shouldn't have been. ...  [It's also one of the reasons I
> personally prefer cygwin over mingw - it is much nicer to have the libc
> runtime do the file name mapping rather than the shell, so that all
> programs do the mapping the same way without the need for wrapper functions.]

This is not true, the argument translation is done in the MSYS libc
runtime not in the shell, so it happens automatically whenever any MSYS
binary exec()s a non-MSYS binary.

Brian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]