Multiple backslashes
Randall R Schulz
rrschulz@cris.com
Sun Feb 10 10:12:00 GMT 2002
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/
More information about the Cygwin
mailing list