* Multiple backslashes @ 2002-02-10 8:55 Dmitry Bely 2002-02-10 9:13 ` Randall R Schulz 0 siblings, 1 reply; 13+ messages in thread From: Dmitry Bely @ 2002-02-10 8:55 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Multiple backslashes 2002-02-10 8:55 Multiple backslashes Dmitry Bely @ 2002-02-10 9:13 ` Randall R Schulz 2002-02-10 9:55 ` Dmitry Bely 0 siblings, 1 reply; 13+ messages in thread From: Randall R Schulz @ 2002-02-10 9:13 UTC (permalink / raw) To: Dmitry Bely, cygwin 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Multiple backslashes 2002-02-10 9:13 ` Randall R Schulz @ 2002-02-10 9:55 ` Dmitry Bely 2002-02-10 10:12 ` Randall R Schulz 0 siblings, 1 reply; 13+ messages in thread From: Dmitry Bely @ 2002-02-10 9:55 UTC (permalink / raw) To: Randall R Schulz; +Cc: cygwin 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Multiple backslashes 2002-02-10 9:55 ` Dmitry Bely @ 2002-02-10 10:12 ` Randall R Schulz 2002-02-10 10:35 ` Dmitry Bely 0 siblings, 1 reply; 13+ messages in thread From: Randall R Schulz @ 2002-02-10 10:12 UTC (permalink / raw) To: Dmitry Bely, cygwin 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Multiple backslashes 2002-02-10 10:12 ` Randall R Schulz @ 2002-02-10 10:35 ` Dmitry Bely 2002-02-10 10:58 ` Randall R Schulz 0 siblings, 1 reply; 13+ messages in thread From: Dmitry Bely @ 2002-02-10 10:35 UTC (permalink / raw) To: Randall R Schulz; +Cc: Dmitry Bely, cygwin 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Multiple backslashes 2002-02-10 10:35 ` Dmitry Bely @ 2002-02-10 10:58 ` Randall R Schulz 2002-02-10 11:55 ` Dmitry Bely 0 siblings, 1 reply; 13+ messages in thread From: Randall R Schulz @ 2002-02-10 10:58 UTC (permalink / raw) To: Dmitry Bely, cygwin 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Multiple backslashes 2002-02-10 10:58 ` Randall R Schulz @ 2002-02-10 11:55 ` Dmitry Bely 2002-02-10 14:50 ` Randall R Schulz 0 siblings, 1 reply; 13+ messages in thread From: Dmitry Bely @ 2002-02-10 11:55 UTC (permalink / raw) To: Randall R Schulz; +Cc: cygwin 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Multiple backslashes 2002-02-10 11:55 ` Dmitry Bely @ 2002-02-10 14:50 ` Randall R Schulz 2002-02-11 1:35 ` a problem with search path? (was: Multiple backslashes) Dmitry Bely 0 siblings, 1 reply; 13+ messages in thread From: Randall R Schulz @ 2002-02-10 14:50 UTC (permalink / raw) To: Dmitry Bely, cygwin 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* a problem with search path? (was: Multiple backslashes) 2002-02-10 14:50 ` Randall R Schulz @ 2002-02-11 1:35 ` Dmitry Bely 2002-02-11 8:57 ` Randall R Schulz 0 siblings, 1 reply; 13+ messages in thread From: Dmitry Bely @ 2002-02-11 1:35 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: a problem with search path? (was: Multiple backslashes) 2002-02-11 1:35 ` a problem with search path? (was: Multiple backslashes) Dmitry Bely @ 2002-02-11 8:57 ` Randall R Schulz 2002-02-12 8:06 ` Dmitry Bely 0 siblings, 1 reply; 13+ messages in thread From: Randall R Schulz @ 2002-02-11 8:57 UTC (permalink / raw) To: Dmitry Bely, cygwin 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: a problem with search path? (was: Multiple backslashes) 2002-02-11 8:57 ` Randall R Schulz @ 2002-02-12 8:06 ` Dmitry Bely 0 siblings, 0 replies; 13+ messages in thread From: Dmitry Bely @ 2002-02-12 8:06 UTC (permalink / raw) To: Randall R Schulz; +Cc: cygwin 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Multiple backslashes
@ 2002-02-11 5:41 Robinow, David
2002-02-12 2:15 ` Dmitry Bely
0 siblings, 1 reply; 13+ messages in thread
From: Robinow, David @ 2002-02-11 5:41 UTC (permalink / raw)
To: 'Dmitry Bely'; +Cc: cygwin
> 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Multiple backslashes 2002-02-11 5:41 Multiple backslashes Robinow, David @ 2002-02-12 2:15 ` Dmitry Bely 0 siblings, 0 replies; 13+ messages in thread From: Dmitry Bely @ 2002-02-12 2:15 UTC (permalink / raw) To: Robinow, David; +Cc: cygwin "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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2002-02-12 16:06 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-02-10 8:55 Multiple backslashes Dmitry Bely 2002-02-10 9:13 ` Randall R Schulz 2002-02-10 9:55 ` Dmitry Bely 2002-02-10 10:12 ` Randall R Schulz 2002-02-10 10:35 ` Dmitry Bely 2002-02-10 10:58 ` Randall R Schulz 2002-02-10 11:55 ` Dmitry Bely 2002-02-10 14:50 ` Randall R Schulz 2002-02-11 1:35 ` a problem with search path? (was: Multiple backslashes) Dmitry Bely 2002-02-11 8:57 ` Randall R Schulz 2002-02-12 8:06 ` Dmitry Bely 2002-02-11 5:41 Multiple backslashes Robinow, David 2002-02-12 2:15 ` Dmitry Bely
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).