Multiple backslashes

Multiple backslashes

[Dmitry Bely]

This is probably a FAQ, but can you explain me why

bash -c "ls c:\\\\"

requires 4 backslashes? I can understand why 2 BS is needed, but 4 BS IMHO
are too much :-)

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/

Re: Multiple backslashes

[Randall R Schulz]

Dmitry,

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. 
Then the bash invoked by that command interprets the argument to the "-c" 
option. Each of these rounds of interpretation replaces "\\" with "\".

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 ';').

Randall Schulz
Mountain View, CA USA


At 08:45 2002-02-10, Dmitry Bely wrote:
>This is probably a FAQ, but can you explain me why
>
>bash -c "ls c:\\\\"
>
>requires 4 backslashes? I can understand why 2 BS is needed, but 4 BS IMHO 
>are too much :-)
>
>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/

Re: Multiple backslashes

[Dmitry Bely]

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/

Re: Multiple backslashes

[Randall R Schulz]

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/

Re: Multiple backslashes

[Dmitry Bely]

Randall R Schulz <rrschulz@cris.com> writes:

> 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.

OK, I will look into it.

> 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!

Thank you very much for you comments, but I must repeat that in my case
XEmacs calls  bash -c "..." _directly_ via CreateProcess() with _exactly_
the same results. So I still tend to consider the necessity of "\\\\" as a
bug.

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/

Re: Multiple backslashes

[Randall R Schulz]

Dmitry,

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.

 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.
-==-

 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.
-==-

So you see, you can tailor Cygwin's operations to your needs (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.

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?

Randall Schulz
Mountain View, CA USA


At 10:33 2002-02-10, you wrote:
>Randall R Schulz <rrschulz@cris.com> writes:
>
> > 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.
>
>OK, I will look into it.
>
> > 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!
>
>Thank you very much for you comments, but I must repeat that in my case
>XEmacs calls  bash -c "..." _directly_ via CreateProcess() with _exactly_
>the same results. So I still tend to consider the necessity of "\\\\" as a
>bug.
>
>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/

Re: Multiple backslashes

[Dmitry Bely]

Randall R Schulz <rrschulz@cris.com> 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 :-)

>  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.

>  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.

> So you see, you can tailor Cygwin's operations to your needs 

Don't see yet how to do that.

> (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.

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
bash-2.05$

why do you call this "a feature"?

> 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?

Not yet.

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/

Re: Multiple backslashes

[Randall R Schulz]

Dmitry,

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 <rrschulz@cris.com> 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 
doing it.


> >  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
>bash-2.05$
>
>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?
>
>Not yet.

It is for me.


>Hope to hear from you soon,
>Dmitry


Randy


--
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/

a problem with search path? (was: Multiple backslashes)

[Dmitry Bely]

Randall R Schulz <rrschulz@cris.com> writes:

> 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...

Randall, of course it's up to you whether to answer or not. Nonetheless,
thank you for your comments. For everyone else, I don't claim that cygwin
is buggy (although it might be the case). I just trying to understand
what's going on and how to solve my very problems. Randall's advice to add
CYGWIN=noglob _partially_ solves them (yes, really, it makes 2 BS
sufficient then 'bash -c "ls c:\\"' is called via syscall
CreateProcess()). But:

How to write the following command with _backslashes_ to make it work?
Suppose we launch it from bash:

bash-2.05$ bash -c "ls c:\\\\cygwin\\\\bin\\\\ls.exe"
c:\cygwin\bin\ls.exe
bash-2.05$ bash -c "c:\\\\cygwin\\\\bin\\\\ls.exe"
bash: c:\cygwin\bin\ls.exe: command not found
bash-2.05$

CYGWIN=noglob does _not_ help.

How many backslahes should I put there?
But please check that it _really_ works before answering.

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/

Re: a problem with search path? (was: Multiple backslashes)

[Randall R Schulz]

Dmitry,

Did you read the manual sections I referred you to?

CYGWIN=glob (withour without ":ignorecase") vs. CYGWIN=noglob _only_ 
pertains when a non-Cygwin process invokes a Cygwin binary.

Thus, "CYGWIN=[no]glob" is irrelevant when you're invoking a program 
(either Cygwin or Win32) from BASH (Cygwin).

You need to reason about what's happening, not try to apply a single 
cookbook formula. At a minimum, you must know how many times globbing (and, 
hence, escaping) will be applied to any given string.

Randall Schulz
Mountain View, CA USA


At 01:31 2002-02-11, you wrote:
>Randall R Schulz <rrschulz@cris.com> writes:
>
> > 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...
>
>Randall, of course it's up to you whether to answer or not. Nonetheless, 
>thank you for your comments. For everyone else, I don't claim that cygwin 
>is buggy (although it might be the case). I just trying to understand 
>what's going on and how to solve my very problems. Randall's advice to add 
>CYGWIN=noglob _partially_ solves them (yes, really, it makes 2 BS 
>sufficient then 'bash -c "ls c:\\"' is called via syscall 
>CreateProcess()). But:
>
>How to write the following command with _backslashes_ to make it work? 
>Suppose we launch it from bash:
>
>bash-2.05$ bash -c "ls c:\\\\cygwin\\\\bin\\\\ls.exe"
>c:\cygwin\bin\ls.exe
>bash-2.05$ bash -c "c:\\\\cygwin\\\\bin\\\\ls.exe"
>bash: c:\cygwin\bin\ls.exe: command not found
>bash-2.05$
>
>CYGWIN=noglob does _not_ help.
>
>How many backslahes should I put there? But please check that it _really_ 
>works before answering.
>
>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/

Re: a problem with search path? (was: Multiple backslashes)

[Dmitry Bely]

Randall R Schulz <rrschulz@cris.com> writes:

> Did you read the manual sections I referred you to?

Yes.

> CYGWIN=glob (withour without ":ignorecase") vs. CYGWIN=noglob _only_
> pertains when a non-Cygwin process invokes a Cygwin binary.
> 
> Thus, "CYGWIN=[no]glob" is irrelevant when you're invoking a program
> (either Cygwin or Win32) from BASH (Cygwin).

I realize that. I just used "bash inside bash" example to show that the
problem is inside Cygwin/bash, not in cmd<->cygwin or
CreateProcess()<->cygwin interface.

> You need to reason about what's happening, not try to apply a single
> cookbook formula. At a minimum, you must know how many times globbing
> (and, hence, escaping) will be applied to any given string.

I understand all this (I hope). And then I run

C:\>set CYGWIN=noglob
C:\>bash -c "c:\\cygwin\\bin\\ls.exe"
bash: c:\cygwin\bin\ls.exe: command not found

from cmd.exe, I expect that it should work (if not, could you finally
explain me there I am mistaken in this very case and rewrite it
properly). It does not. But in the same time any of the following works:

C:\>set CYGWIN=noglob
C:\>bash -c "c:/cygwin\\bin\\ls.exe"

C:\>set CYGWIN=noglob
C:\>bash -c "..\\bin\\ls.exe"  (c:\cygwin\bin is in the PATH)

That's why I think that the problem is that Cygwin (or bash) fails to
understand that "c:\\cygwin\\bin\\ls.exe" is the _absolute_ path, and tries
to locate ls using PATH directories. I see relatively long delay and HDD
LED blinking before "command not found" message appears (of course if
search directories are not in the file cache). Don't you think that all
this have nothing to do with globbing?

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/

RE: Multiple backslashes

[Robinow, David]

> From: Dmitry Bely [mailto:dbely@mail.ru]
> To: Randall R Schulz
> Cc: Dmitry Bely; cygwin@cygwin.com
> Subject: Re: Multiple backslashes
> Randall R Schulz <rrschulz@cris.com> writes:
> 
> > What I said is accurate. However, in the absence of any explicit
> > 
> > Or, you can do what I strongly suggest to everyone who'll listen:
> > DON'T USE CMD.EXE!
> 
> Thank you very much for you comments, but I must repeat that in my case
> XEmacs calls  bash -c "..." _directly_ via CreateProcess() with _exactly_
> the same results. So I still tend to consider the necessity of "\\\\" as a
> bug.
 Have you looked into the use of the XEmacs variable directory-sep-char ?

--
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/

Re: Multiple backslashes

[Dmitry Bely]

"Robinow, David" <drobinow@dayton.adroit.com> writes:

>  Have you looked into the use of the XEmacs variable setq directory-sep-char?

Hmm, it might really be the solution. Thank you very much for the idea.

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/