This is the mail archive of the
mailing list for the Cygwin project.
Re: Multiple backslashes
I'm trying to help you, but you seem insistent on just declaring Cygwin
buggy. It is not and it is possible for you to resolve the problem. I gave
you all the information you need to do so.
One last time, I'll answer your points...
At 11:46 2002-02-10, you wrote:
>Randall R Schulz <firstname.lastname@example.org> writes:
> > If your XEmacs is a Windows app and not a Cygwin one, then my caveats
> > apply because it is another example of a Windows process initiating a
> > Cygwin program.
>It's not acceptable? How then to invoke the bash itself :-)
I didn't say anything about "acceptable" or "unacceptable." Obviously, bash
is being invoked. There's really just one way and it's the way XEmacs is
> > From the Cygwin FAQ:
> > -==-
> > How does wildcarding (globbing) work?
> > If the DLL thinks it was invoked from a DOS style prompt, it runs a
> > `globber' over the arguments provided on the command line. This means
> > that if you type LS *.EXE from DOS, it will do what you might expect.
> > Beware: globbing uses malloc. If your application defines malloc, that
> > will get used. This may do horrible things to you.
> > -==-
>It has nothing to do with my case. There is no globs, just plain file names.
It doesn't matter that the string you're passing has no glob characters, it
is processed as the shell would ordinarily proccess the string _prior to
invoking the program_. Because glob processing is done, escapes must be
processed, too. That is the source of your problem.
> > From the Cygwin User Guide (".../cygwin-ug-net/using-cygwinenv.html"):
> > -==-
> > (no)glob[:ignorecase] - if set, command line arguments containing
> > UNIX-style file wildcard characters (brackets, question mark,
> > asterisk, escaped with \) are expanded into lists of files that match
> > those wildcards. This is applicable only to programs running from a
> > DOS command line prompt. Default is set.
> > -==-
>Again, no relation.
Yes, it is directly related. Use the "noglob" option and your problem will
be gone. You could at least have tried before writing this.
> > So you see, you can tailor Cygwin's operations to your needs
>Don't see yet how to do that.
Well, then I cannot help you beyond what I've already said. Learn about the
tool you're using--there's no alternative other than stumbling around in
the dark until you happen to get the result you want.
> > (as, of course, you can alter XEmacs to your heart's content).
> > Regardless of whether you consider this behavior a bug, it's one of
> > the seams between the disparate environments (POSIX and Win32) that
> > cannot be completely eradicated. I don't think you're going to get the
> > Cygwin principals to agree that this is a bug. Obviously, it is a
> > feature and what's more, a feature that you can control.
>Which feature? If Win32 paths are not handled properly inside bash, e.g.
Which feature? The "CYGWIN=glob" feature which, as is clearly stated in the
above manual excerpt, is set (on) be default. As I said, turn it off
(CYGWIN=noglob) and you'll get what you want.
>bash-2.05$ bash -c "c:/cygwin/bin/ls.exe"
> [ ... works ... ]
>bash-2.05$ bash -c "c:\\\\cygwin\\\\bin\\\\ls.exe"
>bash: c:\cygwin\bin\ls.exe: command not found
>why do you call this "a feature"?
You're being obtuse.
> > Lastly, don't forget that you need not disable globbing globally. You
> > can always have XEmacs alter the CYGWIN environment locally so it
> > applies only to those sub-processes it initiates. Note that some
> > CYGWIN environment variable options apply globally and are only
> > consulted when the cygwin1.dll is loaded. I don't think this is one,
> > but I'm not sure (and I hope you won't think me lazy for not tracking
> > down that detail!).
> > Case closed?
It is for me.
>Hope to hear from you soon,
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html