From: Eli Z. <el...@gn...> - 2006-01-07 13:10:22
|
> From: "Earnie Boyd" <ea...@us...> > Cc: Eli Zaretskii <el...@gn...> > Date: Sat, 7 Jan 2006 06:17:16 -0500 > > > I simply don't see any reasons to stick to the /foo/bar syntax > > nowadays; the days when that was required are long gone. > > Those days are still around for those packages that haven't upgraded to newer > versions of autotools. Which packages are those? How many such packages do we know about? > MSYS itself will handle c:/ as will as /c. I had no doubt about this, so let's not be side-tracked into discussing this. > Spawning to cmd.exe or command.com though requires a translation to > the backslash form for the spawned process path. I don't think I understand what you mean by ``the spawned process path''. Do you mean the value of PATH that is passed to the child process? If so, then I agree that it needs its slashes be mirrored to backslashes and colons turned to semi-colons. But this has nothing to do with the issue I was talking about: I was talking about messing with _command_line_arguments_. > > The single most important exception from this widespread support for > > d:/foo/bar syntax is stock Windows shells, cmd.exe and command.com. > > (cmd.exe will accept forward slashes if the file name is quoted, but > > let's forget about this for the moment.) So when MSYS invokes a > > program through cmd.exe or command.com, it should convert the slashes > > to backslashes in the first argument passed to the shell, which is a > > path to the program or batch file which the shell should invoke; the > > rest of the arguments should not be modified at all, since they will > > be processed by the invoked program, not by the shell itself. In all > > other cases, no conversion of command-line arguments should take > > place. > > > > Which I see you state here. Sorry, I don't understand what you mean by this. Please explain. > The MSYS user would be angry with me if I didn't convert the paths. Again, if you are talking about PATH, that's another issue. > As a matter of fact, that is one of the reasons I forked > Cygwin to begin with. The translation of paths from POSIX representation to > WINDOWS paths (the translation output is with forward slash, ie: c:/foo/bar) > is a must when spawning the native program for MSYS. I am arguing that you don't need the Posix /c/foo/bar representation at all, you could use c:/foo/bar throughout. And for the command-line arguments, you could simply leave c:/foo/bar file names alone. > One of the things MSYS provides is a mapping of the windows filesystem to a > POSIX one. So if I want /usr/local on drive e:/ while /usr is on drive c: I > can easily work in familiar style. If this mapping is the main reason for trying to interpret command line arguments (instead of simply passing them verbatim to subprograms), then I'd say it's better to toss the mapping feature. When the ported binaries are built, you could configure them with a non-default prefix so that they won't look for files in /usr/local, but in another directory, whose name is given in the d:/foo/bar format. |