Re: Multiple backslashes

[Randall R Schulz <rrschulz at cris dot com>]

Dmitry,

What I said is accurate. However, in the absence of any explicit mention on 
your part, I assumed you were issuing the commands you specified from a 
Cygwin shell. It now appears you are entering them into CMD.exe.

If I'm not mistaken, arguments are processed differently in Cygwin binaries 
when they are invoked from a Windows program than they are when invoked by 
another Cygwin process. Someone who knows better (or the manual...) will 
have to supply details, it's a mode of operation I never encounter (CMD.exe 
offends me deeply...). I have a vague recollection that there is a CYGWIN 
environment variable option that controls or supresses or modifies this 
behavior somehow--I'm even less sure about this than I am about the variant 
argument processing itself.

I believe this is why you're experiencing difficulties. You'll have to 
familiarize yourself with the special argument processing in the Windows -> 
Cygwin transition.

Or, you can do what I strongly suggest to everyone who'll listen: DON'T USE 
CMD.EXE!

Good luck.

Randall Schulz
Mountain View, CA USA


At 09:49 2002-02-10, you wrote:
>Randall R Schulz <rrschulz@cris.com> writes:
>
> > Apart from the fact that this question involves Windows native path
> > name syntax (which, by the way, works equally well with forward
> > slashes), this is not Cygwin-specific.
> >
> >
> > There are two levels or rounds of interpretation of your command
> > string. The first is applied by the shell that interpets the command
> > you mentioned.
>
>No.
>
>C:\Work>cmd /c "ls c:\"
>   [...]
>   works, while
>C:\Work>bash -c "ls c:\\"
>   does not. Why?
>
>
> > Then the bash invoked by that command interprets the
> > argument to the "-c" option. Each of these rounds of interpretation
> > replaces "\\" with "\".
>
>The problem is that the first shell (cmd.exe) does not replace "\\" with
>"\"! And I have found it in the case where bash is the only shell (see below).
>
>OK, another strange behaviour:
>
>C:\Work>bash -c "c:/cygwin/bin/ls.exe"
>   [...]
>   works.
>C:\Work>bash -c "c:\cygwin\bin\ls.exe"
>bash: c:cygwinbinls.exe: command not found
>   as expected.
>C:\Work>bash -c "c:\\cygwin\\bin\\ls.exe"
>bash: c:\cygwin\bin\ls.exe: command not found
>   why???
>C:\Work>bash -c "c:\\\\cygwin\\\\bin\\\\ls.exe"
>bash: c:\\cygwin\\bin\\ls.exe: command not found
>   expected by me, but not by you :-)
>
>bash does something that is beyond my comprehension...
>
> > If you use "hard" quotes (apostrophes) then you'll only need two 
> backslashes.
> >
> > If you use forward slashes (and CMD.exe is not going to be involved),
> > then you'll only need quoting to handle spaces and shell globbing
> > metacharacters (i.e., '*', '?' or '[') and syntactically significant
> > characters (e.g., '(' or ';').
>
>A cannot always use forward slashes. I am trying to make XEmacs/Win32 work 
>with bash shell. It constructs a command like
>
>bash -c "<command line with back slashes>"
>
>which bash does not like. Obviously, I cannot simply replace all 
>backslashes with forward ones, because XEmacs also escapes some 
>metacharacters ...
>
>Hope to hear from you soon,
>Dmitry


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/