Bizarre Cygwin/Explorer/paths problem half-solved

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Bizarre Cygwin/Explorer/paths problem half-solved

Luke Kendall
I discovered today that if I try to run Windows Explorer from the Cygwin
command line, and give it a pathname with spaces, it fails, but if I
give the same command line to a cmd.exe command line, Explorer works!

I.e. from Bash, explorer fails with an error message like
"The path '/e,c:\temp\space dir' does not exist or is not a directory."

I've tried every quote combo I can.  If I leave off the /e option then
it does open the directory, but without the side pane (which is what
you'd expect with the /e option omitted).

Bash shell:

    $ mkdir c:/temp/"space dir"

    $ explorer /e,c:\\temp\\space\ dir
    $ # NBG^
    $ explorer /e,c:\\temp
    $ # GOOD^
    $ explorer c:\\temp\\space\ dir
    $ # GOOD^ (but no side pane)
    $ explorer /e,"c:\temp\space dir"    
    $ # NBG^
    $ explorer /e,"\"c:\temp\space dir\""
    $ # NBG^

DOS shell:

    c>explorer /e,c:\temp\space dir
    c>rem  GOOD^
    c>explorer /e,"c:\temp\space dir"
    c>rem  GOOD^
    c>explorer /e,'c:\temp\space dir'
    c>rem  NBG^
    c>explorer /e,c:\temp\space dir
    c>rem  NBG^

Until I tried the same stuff under the DOS shell, I assumed it was
explorer.exe that was busted.  Now I'm just confused.

I find this quite bizarre.  Any suggestions?  Is bash or Cygwin
guessing the /e option is part of a path, and doing some extra quoting
of its own or something?

I just tried an strace on bash, and it looks like this guess is correct:

  140 4166625 [main] bash 5696 spawn_guts: null_app_name 0
   (c:\WINDOWS\explorer.exe, c:\WINDOWS\explorer.exe "/e,c:\temp\space dir")

It's collected all the arguments and put them inside double quotes, and
if I do that in a DOS shell too I get the exact same failure.

If the directory contains no spaces, then bash does this, in contrast:

12217 33394057 [main] bash 5284 spawn_guts: 5284 = spawn_guts
 (/cygdrive/c/WINDOWS/explorer, c:\WINDOWS\explorer.exe /e,c:\temp)

Is there some way to tell Bash/Cygwin not to do this?  Or is it simply
that my bash is too old?

$ bash --version
GNU bash, version 3.2.9(10)-release (i686-pc-cygwin)
Copyright (C) 2005 Free Software Foundation, Inc.

Regards,

luke

PS: NBG = No Good!



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: Bizarre Cygwin/Explorer/paths problem half-solved

Lev Bishop
On Mon, Aug 4, 2008 at 04:18, Luke Kendall wrote:

>    $ explorer /e,c:\\temp\\space\ dir
>    $ # NBG^
>    $ explorer /e,c:\\temp
>    $ # GOOD^
>    $ explorer c:\\temp\\space\ dir
>    $ # GOOD^ (but no side pane)
>    $ explorer /e,"c:\temp\space dir"
>    $ # NBG^
>    $ explorer /e,"\"c:\temp\space dir\""
>    $ # NBG^

$ explorer /e,C:\\temp\\space dir
$ GOOD^

Lev

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: Bizarre Cygwin/Explorer/paths problem half-solved

Buchbinder, Barry (NIH/NIAID) [E]
In reply to this post by Luke Kendall
Luke Kendall wrote on Monday, August 04, 2008 4:18 AM:

> I discovered today that if I try to run Windows Explorer from the
> Cygwin command line, and give it a pathname with spaces, it fails,
> but if I give the same command line to a cmd.exe command line,
> Explorer works!  
>
> I.e. from Bash, explorer fails with an error message like "The path
> '/e,c:\temp\space dir' does not exist or is not a directory."
>
> I've tried every quote combo I can.  If I leave off the /e option
> then it does open the directory, but without the side pane (which is
> what you'd expect with the /e option omitted).  
>
> Bash shell:
>
>     $ mkdir c:/temp/"space dir"
>
>     $ explorer /e,c:\\temp\\space\ dir
>     $ # NBG^
>     $ explorer /e,c:\\temp
>     $ # GOOD^
>     $ explorer c:\\temp\\space\ dir
>     $ # GOOD^ (but no side pane)
>     $ explorer /e,"c:\temp\space dir"
>     $ # NBG^
>     $ explorer /e,"\"c:\temp\space dir\""
>     $ # NBG^
>
> DOS shell:
>
>     c>explorer /e,c:\temp\space dir
>     c>rem  GOOD^
>     c>explorer /e,"c:\temp\space dir"
>     c>rem  GOOD^
>     c>explorer /e,'c:\temp\space dir'
>     c>rem  NBG^
>     c>explorer /e,c:\temp\space dir
>     c>rem  NBG^
>
> Until I tried the same stuff under the DOS shell, I assumed it was
> explorer.exe that was busted.  Now I'm just confused.
>
> I find this quite bizarre.  Any suggestions?  Is bash or Cygwin
> guessing the /e option is part of a path, and doing some extra
> quoting of its own or something?  
>
> I just tried an strace on bash, and it looks like this guess is
> correct:
>
>   140 4166625 [main] bash 5696 spawn_guts: null_app_name 0
>    (c:\WINDOWS\explorer.exe, c:\WINDOWS\explorer.exe
> "/e,c:\temp\space dir")
>
> It's collected all the arguments and put them inside double quotes,
> and if I do that in a DOS shell too I get the exact same failure.
>
> If the directory contains no spaces, then bash does this, in contrast:
>
> 12217 33394057 [main] bash 5284 spawn_guts: 5284 = spawn_guts
> (/cygdrive/c/WINDOWS/explorer, c:\WINDOWS\explorer.exe /e,c:\temp)
>
> Is there some way to tell Bash/Cygwin not to do this?  Or is it
> simply that my bash is too old?
>
> $ bash --version
> GNU bash, version 3.2.9(10)-release (i686-pc-cygwin) Copyright (C)
> 2005 Free Software Foundation, Inc.

As a work-around, you might try the -x or --explore option of cygstart.
I use it in the following script (which I cal "explore"), though a
shell function might be better if you use this a lot.

====[ cut ]====
#!/bin/bash
/bin/cygstart --explore "${1:-.}"
====[ cut ]====

"${1:-.}" makes explorer open in the current working directory run
without an argument.

If this does not do what you want, you could always try launching
explorer with cygstart (without -x, giving you control of explorer's
command line arguments) or cmd /c start.  And one way to get rid of
spaces is to go to that directory.  You could just

$ pushd /cygpath/c/temp/space\ dir
$ explorer /e,.
$ popd

Good luck!

- Barry
  -  Disclaimer: Statements made herein are not made on behalf of NIAID.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: Bizarre Cygwin/Explorer/paths problem half-solved

Gary R. Van Sickle
In reply to this post by Luke Kendall
Hi Luke,

> I discovered today that if I try to run Windows Explorer from
> the Cygwin command line, and give it a pathname with spaces,
> it fails, but if I give the same command line to a cmd.exe
> command line, Explorer works!
>
> I.e. from Bash, explorer fails with an error message like
> "The path '/e,c:\temp\space dir' does not exist or is not a
> directory."
>
> I've tried every quote combo I can.  If I leave off the /e
> option then it does open the directory, but without the side
> pane (which is what you'd expect with the /e option omitted).
>

I've had this little gem in my .bash_profile for ages, and it's never failed
me regardless of the craziness of the path:

# Easy "Explorer here" command
x()
{
        if [ "${1}" = "" ];
        then
                XPATH=".";
        else
                XPATH="$(cygpath -w "${1}")";
        fi
        explorer $XPATH & disown %-
}

No tree view though.  Lessee what happens if I add a "/e,":

# Easy "Explorer here" command with tree control on the left
x()
{
        if [ "${1}" = "" ];
        then
                # No parameter given, open Explorer in the current bash
directory.
                XPATH=".";
        else
                # Open the given path.
                XPATH="$(cygpath -w "${1}")";
        fi
        explorer /e,$XPATH & disown %-
}

...yep, that works like a charm too.

--
Gary R. Van Sickle


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: Bizarre Cygwin/Explorer/paths problem half-solved

Luke Kendall
In reply to this post by Buchbinder, Barry (NIH/NIAID) [E]
On  4 Aug, Buchbinder, Barry (NIH/NIAID) [E] wrote:

>  Luke Kendall wrote on Monday, August 04, 2008 4:18 AM:
>  
> > I discovered today that if I try to run Windows Explorer from the
> > Cygwin command line, and give it a pathname with spaces, it fails,
> > but if I give the same command line to a cmd.exe command line,
> > Explorer works!  
> >
> > I.e. from Bash, explorer fails with an error message like "The path
> > '/e,c:\temp\space dir' does not exist or is not a directory."
> >
> > I've tried every quote combo I can.  If I leave off the /e option
> > then it does open the directory, but without the side pane (which is
> > what you'd expect with the /e option omitted).  
> >
> > Bash shell:
> >
> >     $ mkdir c:/temp/"space dir"
> >
> >     $ explorer /e,c:\\temp\\space\ dir
> >     $ # NBG^
> >     $ explorer /e,c:\\temp
> >     $ # GOOD^
> >     $ explorer c:\\temp\\space\ dir
> >     $ # GOOD^ (but no side pane)
> >     $ explorer /e,"c:\temp\space dir"
> >     $ # NBG^
> >     $ explorer /e,"\"c:\temp\space dir\""
> >     $ # NBG^
> >
> > DOS shell:
> >
> >     c>explorer /e,c:\temp\space dir
> >     c>rem  GOOD^
> >     c>explorer /e,"c:\temp\space dir"
> >     c>rem  GOOD^
> >     c>explorer /e,'c:\temp\space dir'
> >     c>rem  NBG^
> >     c>explorer /e,c:\temp\space dir
> >     c>rem  NBG^
> >
> > Until I tried the same stuff under the DOS shell, I assumed it was
> > explorer.exe that was busted.  Now I'm just confused.
> >
> > I find this quite bizarre.  Any suggestions?  Is bash or Cygwin
> > guessing the /e option is part of a path, and doing some extra
> > quoting of its own or something?  
> >
> > I just tried an strace on bash, and it looks like this guess is
> > correct:
> >
> >   140 4166625 [main] bash 5696 spawn_guts: null_app_name 0
> >    (c:\WINDOWS\explorer.exe, c:\WINDOWS\explorer.exe
> > "/e,c:\temp\space dir")
> >
> > It's collected all the arguments and put them inside double quotes,
> > and if I do that in a DOS shell too I get the exact same failure.
> >
> > If the directory contains no spaces, then bash does this, in contrast:
> >
> > 12217 33394057 [main] bash 5284 spawn_guts: 5284 = spawn_guts
> > (/cygdrive/c/WINDOWS/explorer, c:\WINDOWS\explorer.exe /e,c:\temp)
> >
> > Is there some way to tell Bash/Cygwin not to do this?  Or is it
> > simply that my bash is too old?
> >
> > $ bash --version
> > GNU bash, version 3.2.9(10)-release (i686-pc-cygwin) Copyright (C)
> > 2005 Free Software Foundation, Inc.
>  
>  As a work-around, you might try the -x or --explore option of cygstart.
>  I use it in the following script (which I cal "explore"), though a
>  shell function might be better if you use this a lot.
>  
>  ====[ cut ]====
>  #!/bin/bash
>  /bin/cygstart --explore "${1:-.}"
>  ====[ cut ]====
>  
>  "${1:-.}" makes explorer open in the current working directory run
>  without an argument.
>  
>  If this does not do what you want, you could always try launching
>  explorer with cygstart (without -x, giving you control of explorer's
>  command line arguments) or cmd /c start.  And one way to get rid of
>  spaces is to go to that directory.  You could just
>  
>  $ pushd /cygpath/c/temp/space\ dir
>  $ explorer /e,.
>  $ popd

I'd have to cygpath it to Unix format first ...

I found your cygstart suggestion a nicer approach - thanks!  It works
well, except that none of the options to prevent the window from taking
focus work when explorer is the thing that gets started.  That's
annoying when I run my script to restore bash/Explorer/Internet Explorer
session (i.e. windows) in interactive mode, but I can live with it.
 
Thanks again!

luke

>  Good luck!
>  
>  - Barry
>    -  Disclaimer: Statements made herein are not made on behalf of NIAID.
>  



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: Bizarre Cygwin/Explorer/paths problem half-solved

Luke Kendall
In reply to this post by Gary R. Van Sickle
On  4 Aug, Gary R. Van Sickle wrote:

>  Hi Luke,
>  
> > I discovered today that if I try to run Windows Explorer from
> > the Cygwin command line, and give it a pathname with spaces,
> > it fails, but if I give the same command line to a cmd.exe
> > command line, Explorer works!
> >
> > I.e. from Bash, explorer fails with an error message like
> > "The path '/e,c:\temp\space dir' does not exist or is not a
> > directory."
> >
> > I've tried every quote combo I can.  If I leave off the /e
> > option then it does open the directory, but without the side
> > pane (which is what you'd expect with the /e option omitted).
> >
>  
>  I've had this little gem in my .bash_profile for ages, and it's never failed
>  me regardless of the craziness of the path:
>  
>  # Easy "Explorer here" command
>  x()
>  {
>   if [ "${1}" = "" ];
>   then
>   XPATH=".";
>   else
>   XPATH="$(cygpath -w "${1}")";
>   fi
>   explorer $XPATH & disown %-
>  }
>  
>  No tree view though.  Lessee what happens if I add a "/e,":
>  
>  # Easy "Explorer here" command with tree control on the left
>  x()
>  {
>   if [ "${1}" = "" ];
>   then
>   # No parameter given, open Explorer in the current bash
>  directory.
>   XPATH=".";
>   else
>   # Open the given path.
>   XPATH="$(cygpath -w "${1}")";
>   fi
>   explorer /e,$XPATH & disown %-
>  }
>  
>  ...yep, that works like a charm too.

True, and thanks, that's interesting!


Don't try this variant, though, since it doesn't work:

    explorer /e,"$XPATH" & disown %-

What happens if you try that innocuous-looking variant is that Cygwin
(or bash?) normalises the path /e,... to a windows path first, producing
\e,...

Well, I though that snippet of info interesting enough to share.

Regards,

luke


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: Bizarre Cygwin/Explorer/paths problem half-solved

Lev Bishop
On Fri, Aug 8, 2008 at 02:41, Luke Kendall wrote:

> Don't try this variant, though, since it doesn't work:
>
>    explorer /e,"$XPATH" & disown %-
>
> What happens if you try that innocuous-looking variant is that Cygwin
> (or bash?) normalises the path /e,... to a windows path first, producing
> \e,...

Well, yes obviously. This is the difference between:

On Mon, Aug 4, 2008 at 07:04, Lev Bishop  wrote:
> On Mon, Aug 4, 2008 at 04:18, Luke Kendall wrote:
>
>>    $ explorer /e,"\"c:\temp\space dir\""
>>    $ # NBG^
>
> $ explorer /e,C:\\temp\\space dir
> $ GOOD^

Lev

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: Bizarre Cygwin/Explorer/paths problem half-solved

Tim McDaniel-2
In reply to this post by Luke Kendall
On Fri, 8 Aug 2008, Luke Kendall wrote:

> On  4 Aug, Gary R. Van Sickle wrote:
>>   explorer /e,$XPATH & disown %-
>
> Don't try this variant, though, since it doesn't work:
>
>    explorer /e,"$XPATH" & disown %-
>
> What happens if you try that innocuous-looking variant is that
> Cygwin (or bash?) normalises the path /e,... to a windows path
> first, producing \e,...

I'm an utter fanatic about quoting to make sure that what I have in
variables isn't munged.  So I'm dismayed to learn that quoting can
*cause* munging and that something munges values in new and exciting
ways.

Is there any documentation on who rewrites arguments, under what
conditions, and how they're altered?

--
Tim McDaniel, [hidden email]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: Bizarre Cygwin/Explorer/paths problem half-solved

Christopher Faylor-8
On Fri, Aug 08, 2008 at 10:16:57AM -0500, Tim McDaniel wrote:

> On Fri, 8 Aug 2008, Luke Kendall wrote:
>> On  4 Aug, Gary R. Van Sickle wrote:
>>>   explorer /e,$XPATH & disown %-
>>
>> Don't try this variant, though, since it doesn't work:
>>
>>    explorer /e,"$XPATH" & disown %-
>>
>> What happens if you try that innocuous-looking variant is that
>> Cygwin (or bash?) normalises the path /e,... to a windows path
>> first, producing \e,...
>
> I'm an utter fanatic about quoting to make sure that what I have in
> variables isn't munged.  So I'm dismayed to learn that quoting can
> *cause* munging and that something munges values in new and exciting
> ways.
>
> Is there any documentation on who rewrites arguments, under what
> conditions, and how they're altered?

I missed this when it was first mentioned.  Cygwin doesn't munge command
line arguments.  Why would it assume that /e,something was a windows
path?  That makes no sense.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: Bizarre Cygwin/Explorer/paths problem half-solved

Lev Bishop
On Fri, Aug 8, 2008 at 12:28, Christopher Faylor  wrote:

>> Is there any documentation on who rewrites arguments, under what
>> conditions, and how they're altered?
>
> I missed this when it was first mentioned.  Cygwin doesn't munge command
> line arguments.  Why would it assume that /e,something was a windows
> path?  That makes no sense.

Nobody is munging anything.

What's going on here is as simple as the difference:

bash-3.2$ cmd /c echo "a b c"
"a b c"
bash-3.2$ cmd /c echo a b c
a b c

There's really no more to it than that.

Lev

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: Bizarre Cygwin/Explorer/paths problem half-solved

Christopher Faylor-8
On Fri, Aug 08, 2008 at 01:39:49PM -0400, Lev Bishop wrote:

>On Fri, Aug 8, 2008 at 12:28, Christopher Faylor  wrote:
>
>>> Is there any documentation on who rewrites arguments, under what
>>> conditions, and how they're altered?
>>
>> I missed this when it was first mentioned.  Cygwin doesn't munge command
>> line arguments.  Why would it assume that /e,something was a windows
>> path?  That makes no sense.
>
>Nobody is munging anything.
>
>What's going on here is as simple as the difference:
>
>bash-3.2$ cmd /c echo "a b c"
>"a b c"
>bash-3.2$ cmd /c echo a b c
>a b c
>
>There's really no more to it than that.

Yes.  I understand.  There was one message which indicated that cygwin
was converting paths on the command line which is, of course, nonsense.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: Bizarre Cygwin/Explorer/paths problem half-solved

Tim McDaniel-2
In reply to this post by Lev Bishop
On Fri, 8 Aug 2008, Lev Bishop <[hidden email]> wrote:
> On Fri, Aug 8, 2008 at 12:28, Christopher Faylor  wrote:
>
>>> Is there any documentation on who rewrites arguments, under what
>>> conditions, and how they're altered?
>>
>> I missed this when it was first mentioned.

I've skipped parts of this thread, so my reply here may well be
repeating something recently said.

>> Cygwin doesn't munge command line arguments.  Why would it assume
>> that /e,something was a windows path?  That makes no sense.
>
> Nobody is munging anything.
>
> What's going on here is as simple as the difference:
>
> bash-3.2$ cmd /c echo "a b c"
> "a b c"
> bash-3.2$ cmd /c echo a b c
> a b c
>
> There's really no more to it than that.

Actually, bash *does* munge arguments passed to Windows commands,
but by surrounding them with double quotes when invoking the commands,
not by translating paths.  To wit:

Except that on 4 Aug, Gary R. Van Sickle wrote:

>  # Easy "Explorer here" command with tree control on the left
>  x()
>  {
>   if [ "${1}" = "" ];
>   then
>   # No parameter given, open Explorer in the current directory.
>   XPATH=".";
>   else
>   # Open the given path.
>   XPATH="$(cygpath -w "${1}")";
>   fi
>   explorer /e,$XPATH & disown %-
>  }

and Luke replied
> Don't try this variant, though, since it doesn't work:
>
>     explorer /e,"$XPATH" & disown %-
>
> What happens if you try that innocuous-looking variant is that
> Cygwin (or bash?) normalises the path /e,... to a windows path
> first, producing \e,...

I used this function, to control the quoting and to avoid stomping on
/usr/bin/X11/x:

     # Source this file only.
     xx()
     {
          WHICH=explorer
          # WHICH=local/test/032.bat
          # WHICH="cmd /c $WHICH"
          if [[ $2 = "" ]];
          then
                  # No parameter given, open Explorer in the current directory.
                  XPATH=.;
          else
                  # Open the given path.
                  XPATH=$(cygpath -w "$2");
          fi
          if [[ $1 = quote ]]; then
              (set -x; $WHICH /e,"$XPATH") & disown %-
          else
              (set -x; $WHICH /e,$XPATH) & disown %-
          fi
     }

Luke is halfway correct: quoting $XPATH can make it fail, but
apparently not for the reason he thinks.  If xx is called as
     xx noquote '/Program Files'
(that is, avoiding quoting of $XPATH), it works, but
     xx quote '/Program Files'
results in a Windows Explorer error window saying
     The path '/e,C:\Program Files' does not exist or is not a
     directory.

Mucking about in a cmd window shows that
     explorer /e,C:\Program Files
gives the correct result while
     explorer "/e,C:\Program Files"
gives the same Windows Explorer error window as above.
And explorer insists on ",", not a space.  That all totally sucks.

(I was curious:
     explorer '/e,C:\Program Files'
gives the error box but saying that 'C:\Program Files' doesn't exist.)

Doing a simple test:

     #! /bin/bash
     XPATH='C:\Program Files'
     if [[ $1 = quote ]]; then
         (set -x; local/test/032.bat /e,"$XPATH") & disown %-
     else
         (set -x; local/test/032.bat /e,$XPATH) & disown %-
     fi

where 032.bat is

     @echo off
     echo in bat
     for %%f in (%*) do echo arg %%f

I find that, with /e,$XPATH, bash just passes it down as separate
arguments,
     arg /e
     arg C:\Program
     arg Files
but with /e,"$XPATH", bash actually passes a real double-quoted
string:
     arg "/e,C:\Program Files"
which explorer.exe refuses to accept because it's idiotic
as aforesaid.
     explorer /e,"C:\Program Files"
would work too, but I don't see how to get bash to generate it.

That's most unpleasant.  I don't suppose there's any way to control
Cygwin's bash in re where to put double quotes around arguments being
passed to a Windows command (since getting Microsoft to make
explorer.exe be sane is hopeless)?  Except by not using characters
that bash thinks need quoting.

I found two workarounds that have safe quoting of $XPATH:
     XPATH=$(cygpath -s -w "$2");  # produce the Windows short name
     ...
     cmd /c explorer /e,"$XPATH"
(that's the "not using characters that need quoting" path) or
     XPATH=$(cygpath -w "$2");
     ...
     cmd /c "explorer /e,$XPATH"

Again, my apologies if this has all been covered recently -- I was too
lazy to check the list archives as I should have.

--
Tim McDaniel, [hidden email]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: Bizarre Cygwin/Explorer/paths problem half-solved

Christopher Faylor-8
On Fri, Aug 08, 2008 at 01:58:12PM -0500, Tim McDaniel wrote:
>That's most unpleasant.  I don't suppose there's any way to control
>Cygwin's bash in re where to put double quotes around arguments being
>passed to a Windows command (since getting Microsoft to make
>explorer.exe be sane is hopeless)?  Except by not using characters that
>bash thinks need quoting.

I'd be very surprised if bash was doing anything different for Windows
than it does for linux.  cygwin1.dll does do some quoting of arguments
to non-cygwin programs if it thinks it is required.  But, no, we're not
going to implement a complicated scheme to turn that off for random
programs.  If you don't like the behavior, right a C program to fix
things up.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: Bizarre Cygwin/Explorer/paths problem half-solved

Tim McDaniel-2
On Fri, 8 Aug 2008, Christopher Faylor <[hidden email]> wrote:

> On Fri, Aug 08, 2008 at 01:58:12PM -0500, Tim McDaniel wrote:
>> That's most unpleasant.  I don't suppose there's any way to control
>> Cygwin's bash in re where to put double quotes around arguments
>> being passed to a Windows command (since getting Microsoft to make
>> explorer.exe be sane is hopeless)?  Except by not using characters
>> that bash thinks need quoting.
>
> I'd be very surprised if bash was doing anything different for
> Windows than it does for linux.  cygwin1.dll does do some quoting of
> arguments to non-cygwin programs if it thinks it is required.

Well, *something* had to be adding the double-quotes.  It's execve()
and such adding them, then?

> But, no, we're not going to implement a complicated scheme to turn
> that off for random programs.

--
Tim McDaniel, [hidden email]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: Bizarre Cygwin/Explorer/paths problem half-solved

Lev Bishop
On Fri, Aug 8, 2008 at 15:47, Tim McDaniel  wrote:

> On Fri, 8 Aug 2008, Christopher Faylor
> <[hidden email]> wrote:
>>
>> On Fri, Aug 08, 2008 at 01:58:12PM -0500, Tim McDaniel wrote:
>>>
>>> That's most unpleasant.  I don't suppose there's any way to control
>>> Cygwin's bash in re where to put double quotes around arguments
>>> being passed to a Windows command (since getting Microsoft to make
>>> explorer.exe be sane is hopeless)?  Except by not using characters
>>> that bash thinks need quoting.
>>
>> I'd be very surprised if bash was doing anything different for
>> Windows than it does for linux.  cygwin1.dll does do some quoting of
>> arguments to non-cygwin programs if it thinks it is required.
>
> Well, *something* had to be adding the double-quotes.  It's execve()
> and such adding them, then?

Yes. Windows doesn't have an argv array. Windows programs just get a
single string for their command line from CreateProcess(). It's up to
them how they parse it. Cygwin execv() turns
argv[]={"list","of","arguments with spaces or","not"} into
lpCommandLine="list of \"arguments with spaces or\" not".

Look in winf.cc linebuf::fromargv() . It's set up to work right for
the way cmd.exe parses command lines, with all it's stupid details.
But because each windows program gets to choose how to deal with
quoting and spaces, of course explorer.exe deals with them
differently.

Lev

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: Bizarre Cygwin/Explorer/paths problem half-solved

Christopher Faylor-8
In reply to this post by Christopher Faylor-8
On Fri, Aug 08, 2008 at 03:29:48PM -0400, Christopher Faylor wrote:

>On Fri, Aug 08, 2008 at 01:58:12PM -0500, Tim McDaniel wrote:
>>That's most unpleasant.  I don't suppose there's any way to control
>>Cygwin's bash in re where to put double quotes around arguments being
>>passed to a Windows command (since getting Microsoft to make
>>explorer.exe be sane is hopeless)?  Except by not using characters that
>>bash thinks need quoting.
>
>I'd be very surprised if bash was doing anything different for Windows
>than it does for linux.  cygwin1.dll does do some quoting of arguments
>to non-cygwin programs if it thinks it is required.  But, no, we're not
>going to implement a complicated scheme to turn that off for random
>programs.  If you don't like the behavior, right a C program to fix
                                            write
>things up.

Right.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: Bizarre Cygwin/Explorer/paths problem half-solved

Christopher Faylor-8
In reply to this post by Tim McDaniel-2
On Fri, Aug 08, 2008 at 02:47:43PM -0500, Tim McDaniel wrote:

> On Fri, 8 Aug 2008, Christopher Faylor
> <[hidden email]> wrote:
>> On Fri, Aug 08, 2008 at 01:58:12PM -0500, Tim McDaniel wrote:
>>> That's most unpleasant.  I don't suppose there's any way to control
>>> Cygwin's bash in re where to put double quotes around arguments
>>> being passed to a Windows command (since getting Microsoft to make
>>> explorer.exe be sane is hopeless)?  Except by not using characters
>>> that bash thinks need quoting.
>>
>> I'd be very surprised if bash was doing anything different for
>> Windows than it does for linux.  cygwin1.dll does do some quoting of
>> arguments to non-cygwin programs if it thinks it is required.
>
> Well, *something* had to be adding the double-quotes.  It's execve()
> and such adding them, then?

I said cygwin1.dll.  Isn't that all-encompassing enough?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/