On Sun, Mar 30, 2008 at 9:36 PM, Keith Marshall
> On Sunday 30 March 2008 17:15, James Kanze wrote:
> > I downloaded the latest MSys a week or so ago; it didn't have
> > bash, at least as such, so I also downloaded the version of bash
> > from MinWG, and installed it in /usr/local/bin.
> You should have sh.exe in /bin -- this is actually bash, but
> may be a v2 release. If you then downloaded the v3 update,
> which is recommended, then you should also install it in
> > This is the shell I'm using.
> > The problem I'm having is that bash is apparently expanding
> > command line arguments that start with a /, i.e. if I invoke:
> > cl /help
> This is by design; MSYS accepts UNIX paths, with the root
> representing the MSYS installation directory, (nominally
> c:/msys/1.0, as you have installed it), and it translates
> these to their native equivalents, so
> > , the Microsoft compiler complains that it cannot find file
> > c:/msys/1.0/help,
> This is exactly as you've asked it to do; compile a file
> called /help.
No I didn't. I asked cl to output its help.
> > rather than outputting its help.
> You use UNIX syntax, in the MSYS shell, so to get the help, you use
> cl -help
Under Unix, this isn't way it works. Under Unix, the shell
passes the arguments down to the command, and the command
decides what to do with them. cl isn't a Unix program, and so
obviously follows other conventions.
If I didn't need to run non-Unix programs, I wouldn't bother
with MSys, since I wouldn't have Windows installed. The only
reason I can think of to use MSys is to be able to run non-Unix
programs in an environment which looks somewhat like Unix. The
mapping of a '/' doesn't help much, because for most Windows
programs, that is the sign for an option. If I cannot pass it
to a Windows program, then there's no point in trying to use
> > I wrote a simple program, compiled it with cl, and found
> > that this is what it actually sees as the first argument
> > (or any command line argument). This makes the shell close
> > to unusable,
> It is very usable, if you use it correctly.
I'm trying to use it like a normal Unix shell.
> > since / is the standard character for an option under Windows. (cl
> > will also accept -, but this is not true for all programs.)
> If you do need to run a program which insists on `/', rather than accept
> `-' as the switchar, then you must double the `/'
> cl //help
OK. That's what I was looking for. (It's not quite as simple
as that, since my subshells are in fact invoked via make, and
I'm not always sure when make invokes a shell, and when it tries
to invoke the commandes directly. And of course, it means that
my makefiles will have to be dependent on whether I'm using
MSys, UWin or CygWin---I'd really have preferred avoiding that,
although I suspect that it wouldn't be possible even without
It would still be much better if there were an option to turn
this off, or at least limit it to paths starting /usr, /bin,
etc. (one of the standard supported subdirectories of root). In
my case, for example, filenames are mostly relative, and all of
the absolute filenames are generated by make, directly in
Windows format. And of course, the true Unix philosophy would
be to just pass the names as arguments, unchanged, with a
separate mapping program that you could invoke via `...` when
you explicitly wanted it.
> This is documented, in the readme.rtf file which accompanies
I'm not sure I have anything installed which can read .rtf, but
I suppose OpenOffice can handle it if I copy it over to my Linux
machine. (I've only got that installed because it came with
Linux; my usual tool for text is LaTeX.)
James Kanze (GABI Software) email:james.kanze@...
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34