Snaury wrote:
>
> On 7/10/05, Lennart Borgman <lennart.borgman.073@...> wrote:
> > Thanks for trying to help. I am however unsure what you mean. The
> > examples above all use the same syntax for the path. This syntax is
> > accepted by nearly all w32 apps. Is there any reason MSYS should
> > translate the path name then? (I assume that you mean that MSYS does
> > this translation? It seems to me too.)
Uh, please look again, keeping in mind that the 'official' windows syntax
uses '\' (which has to be 'escaped' in POSIX so you have to type '\\' when
you mean '\') and that using the '/' as a path separator is an extension
ceded to us old fashioned POSIX buffs with a certain amount of high nosed
sniffing going on. Also keep in mind that you are typing into sh.exe which
is a POSIX compliant shell which really does not understand Windowy paths
at all. It is only when some external executable gets invoked that you'll
see the MSys compatibility process come into action. As far as it is
concerned ANY executable could be one of those with its nose so far up in
the air that it can hardly breath. While it's only been a couple weeks
since I read that code, it was complicated enough and I was not really
interested enough to set the details in my mind. I remember seeing a
search for '/'s and '\\'s being one of the prime determinants of which
syntax the code thought it was starting with. Once it had decided that
it was in POSIX mode, it will consider ':' as a list element separator and
translate it to ';'. On the other hand, if it doesn't see a '/' or a '\\'
it looks for an initial letter and a ':' because it will then stick in a
'\\' after the ':' to simplify the context. However, I could be missing
a detail or two since I was actually looking for something else at the
time.
> I don't really know what exactly might cause that problem, but I
> remember that main MSYS advantage is that it automatically translates
> paths into dos-style. However, there's a workaround when this is
> undesireable: using // instead of /.
IIRC there were comments describing a rather nasty situation where
this kluge was adopted as a work-around. Other than calling a few
names and muttering under my breath about being 'too inventive', I'm
going to let this particular sleeping dog lie.
> As a speculation, maybe it sees
> ':' (in unix it is a path separator), splits the path, and then sees
> absolute path which it now has to translate.
Yep.
> > Maybe there is one: cmd.exe (and command.com) does not understand this
> > syntax. This is the only exception I know of, but it may be an important
> > one. Is this the reason MSYS does this path translation? Could it be
> > limited to the case when the app that should get the args really are
> > cmd.exe? (In the examples above the app is of course emacs.exe.)
Think about this problem: If there is at least one snotty program that
will not accept POSIX syntax, and there may be some unknown number of
others that are as inflexible, and they all MUST accept the Windowy
syntax, how would YOU solve the problem?
> I think that you are talking about NT family, because it has posix
> layer, and most of NT file functions support '/' as a separator. But
> is this really true for Win95 for instance?
All of windows (NT, 9x, ME, XP...) applications with the exception of
some ancient stuff 'borrowed' from CPM are written in C, C++ or
something that is compatible with C or C++ at some level. That means
that the C Runtime gets into the act and it was written by POSIXy folks.
The deep stuff like KERNEL32.DLL and USER32.DLL and especially the
ancient code tied to the INT interface does NOT understand POSIX.
> > There may be other examples, but I doubt that there are any serious apps
> > because the underlying libraries that reads and writes the files
> > understand this path syntax as far as I know. (cmd.exe is a strange
> > exception, but I guess it has to do with a bad(?) decision somewhere in
> > the history that args should start with /.)
That decision was made in the late '60s if not even earlier. All of the
DEC operating systems (DOS-11, RT-11, RSTS/E and the many flavors of RSX)
all used '/' as a 'switch' delimiter much like '-' is used in POSIX.
While I don't know for sure, I think it was also used in TOPS.
> Maybe it is because cmd.exe has '/' as a switch specifier (/c /k etc),
> and historically (from old command.com) it accepts "tight" style, when
> you could write something like this:
>
> command/c format/q C:
>
> > 1) Translate only when the path is absolute and in unix format
> > 2) Translate to the path syntax used above then.
> > 3) .. but handle cmd.exe as a special case (translate to the backslash
> > w32 format).
Sorry (3) is almost certainly going to get thrown against the wall. How
do you know that someone hasn't copied CMD.EXE to OHJOY.EXE or something
else as equally inane? ANYTHING could be CMD.EXE (or COMMAND.COM) and
trying to build any extensible method of getting that information into
the places it will be needed is going to create an absolutely HUGE mess.
No, the workable solution is to translate ALL path names that are not
already in Windows format into Windows format. EVERY Windows program
HAS to know how to deal with Windows path specifications. Any other
syntax is optional and not assured to work.
> Well, I personally don't think it's doing anything wrong, and most
> certainly it translates paths only when they begin with /. Also, there
> seems to be some special case for parentheses. I've written a quick
> test script:
>
> #!/bin/sh
> cmd //c echo "/some/path/to"
> cmd //c echo "some/path/to"
> cmd //c echo 'c:/some/path/to'
> cmd //c echo "c:/some/path/to"
> cmd //c echo 'c://some//path//to'
> cmd //c echo "c://some//path//to"
> cmd //c echo '"some/path/to"'
> cmd //c echo '"/some/path/to"'
> cmd //c echo '"c:/some/path/to"'
> cmd //c echo '("c:/some/path/to")'
> cmd //c echo '(c:/some/path/to)'
> cmd //c echo -eval '(setq foo "c:/bar")'
> cmd //c echo -eval '(setq foo "c://bar")'
>
> And here are the results:
>
> D:/Alex/msys/some/path/to
> some/path/to
> c:/some/path/to
> c:/some/path/to
> c://some//path//to
> c://some//path//to
> "\"some/path/to\""
> "\"D:/Alex/msys/some/path/to\""
> "\"c:/some/path/to\""
> "(\"c;D:\Alex\msys\some\path\to\")"
> (c;D:\Alex\msys\some\path\to)
> -eval "(setq foo \"c;D:\Alex\msys\bar\")"
> -eval "(setq foo \"c://bar\")"
>
> Hmm, and now I too start thinking this is strange. Why parentheses are
> treated so specially? o.O
>
> > Do you see any drawbacks with such a scheme?
>
> There might be infinite number of applications apart cmd.exe not
> accepting '/' as a separator, plus you forget about Win9x, and this
> just sounds wrong to me. The only strangeness so far is this specialty
> of parentheses...
Very strange. I expected anything that started D: would continue with
a '\'. Some of this may be interaction between SH.EXE and the path.cc
module in MSys. I'm still trying to touch ground on the source
environment of MinGW and MSys so I will not be able to dig out the
details of this any time soon.
(Wow. It's finished the first four or five tools and there are at least
twice that many to go. What's it been? three or four hours? No I
started about 11 so that's almost six hours. I'll need to check the
logs, but that's going to have to wait until morning. And some of the
earlier runs did 'real' installs instead of putting the results in
separate directories where I can check them, so I'm going to have to
start over at least one more time. If I'm going to be able to fix
real problems, I really need to know where I'm starting from. I tried
a 'HEAD' build a couple days ago and the results were NOT usable by me,
but Earnie's using at least some of it, so I'm still floundering...)
Max
|
