cygpath

cygpath

[Laurent Charles]

Hello,

When I use cygpath as follows;
 cygpath -w "/usr/local/bin/tool -f /usr/src/source.c"
It replies;
 U:\local\bin\tool -f \usr\src\source.c

The remote volume U: is mounted as /usr

Is cygpath supposed to reply (which is the behaviour I expected)
 U:\local\bin\tool -f U:\src\source.c
Or is it not implemented? a bug? not at all featured by cygpath?

I use b20 from binary distribution (full.exe)

Thank you for your reply.

--Laurent
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: cygpath

[Rick Rankin]

I think the more typical usage would be

/usr/local/bin/tool -f $(cygpath -w /usr/src/source.c)

Correct me if I'm wrong, but my understanding of cygpath is that it converts
a (single) path between formats, not all paths in a command.

--
Rick Rankin
rrankin@primenet.com

> -----Original Message-----
> From: owner-gnu-win32@cygnus.com [ mailto:owner-gnu-win32@cygnus.com]On
> Behalf Of Laurent Charles
> Sent: Tuesday, November 10, 1998 7:18 AM
> To: gnu-win32
> Subject: cygpath
>
>
> Hello,
>
> When I use cygpath as follows;
>  cygpath -w "/usr/local/bin/tool -f /usr/src/source.c"
> It replies;
>  U:\local\bin\tool -f \usr\src\source.c
>
> The remote volume U: is mounted as /usr
>
> Is cygpath supposed to reply (which is the behaviour I expected)
>  U:\local\bin\tool -f U:\src\source.c
> Or is it not implemented? a bug? not at all featured by cygpath?
>
> I use b20 from binary distribution (full.exe)
>
> Thank you for your reply.
>
> --Laurent
> -
> For help on using this list (especially unsubscribing), send a message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".
>

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: cygpath

[Laurent Charles]

I'm sorry if I've not been clear.

laurent.charles@st.com wrote:
> When I use cygpath as follows;
>  cygpath -w "/usr/local/bin/tool -f /usr/src/source.c"
> It replies;
>  U:\local\bin\tool -f \usr\src\source.c

'-f' is an option of 'tool'.

The purpose of the above usage of cygwin was to have a "unix-like"
command line totally converted to a "windows-like" (the command line I
put between quotes).
In my example, 'tool' is a windows executable that does not understand
paths with '/'.

I understand from some of your answers (and I looked in the cygpath
source file) that cygpath can only convert one file/directory name at a
time, not a full command line.
However as it does a bit of the job on the end of the command line, I
expected it to be able to do the whole job.

In my idea, such tool would be interesting to have windows tools within
cygwin processes, make, or any script.
Especially, it may be a first step towards a wrapper to have another
compiler than gcc to compile things. We may imagine that cygpath (or a
derived tool) could convert a 'gcc' command line to a 'cl' command line
or to have gcc used within DevStudio.
ex: '/usr/local/bin/gcc -g /usr/src/source.c' may become something such
as 'd:\devstudio\vc\bin\cl /G u:\src\source.c'

However, in a first step, do you think extending cygpath is a bad idea
and that it will change its current behaviour?

--Laurent
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: cygpath

[Earnie Boyd]

---Laurent Charles <laurent.charles@st.com> wrote:
>
> Hello,
> 
> When I use cygpath as follows;
>  cygpath -w "/usr/local/bin/tool -f /usr/src/source.c"
> It replies;
>  U:\local\bin\tool -f \usr\src\source.c
> 

What is the -f option?  cygpath --help only shows -w, -u and -p



==
-                  \\||//
-------------o0O0--Earnie--0O0o--------------
--          earnie_boyd@yahoo.com          --
-- http://www.freeyellow.com/members5/gw32 --
----------------ooo0O--O0ooo-----------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: cygpath

[Rick Rankin]

I think the -f option is supposed to be an option to /usr/local/bin/tool
command, not to cygpath.

--
Rick Rankin
rrankin@primenet.com

> -----Original Message-----
> From: owner-gnu-win32@cygnus.com [ mailto:owner-gnu-win32@cygnus.com]On
> Behalf Of Earnie Boyd
> Sent: Wednesday, November 11, 1998 5:23 AM
> To: Laurent Charles; gnu-win32
> Subject: Re: cygpath
>
>
> ---Laurent Charles <laurent.charles@st.com> wrote:
> >
> > Hello,
> >
> > When I use cygpath as follows;
> >  cygpath -w "/usr/local/bin/tool -f /usr/src/source.c"
> > It replies;
> >  U:\local\bin\tool -f \usr\src\source.c
> >
>
> What is the -f option?  cygpath --help only shows -w, -u and -p
>
>
>
> ==
> -                  \\||//
> -------------o0O0--Earnie--0O0o--------------
> --          earnie_boyd@yahoo.com          --
> -- http://www.freeyellow.com/members5/gw32 --
> ----------------ooo0O--O0ooo-----------------
>
> PS: Newbie's, you should visit my page.
> _________________________________________________________
> DO YOU YAHOO!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> -
> For help on using this list (especially unsubscribing), send a message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".
>

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: cygpath

[DJ Delorie]

The cygpath program takes a *single* filename as its
parameter, not a complete command line.  When it saw
the complete command line you gave it:

 cygpath -w "/usr/local/bin/tool -f /usr/src/source.c"

It treated that string as a single filename that happened
to include the subdirectory "/tool -f /" and properly
converted the entire string to a single Windows path name.

I think what you wanted to do was this:

 /usr/local/bin/tool -f `cygpath -w /usr/src/source.c`

If you have a posix path, chances are, you're running bash
or some script that understands them, so don't
convert that.  Else, do that conversion too.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: cygpath

[Earnie Boyd]

What happens if you write it this way:

BASH$ /usr/local/bin/tool -f `cygpath -w /usr/src/source.c`




---Rick Rankin <rrankin@primenet.com> wrote:
>
> I think the -f option is supposed to be an option to
/usr/local/bin/tool
> command, not to cygpath.
> 
> --
> Rick Rankin
> rrankin@primenet.com
> 
> > -----Original Message-----
> > From: owner-gnu-win32@cygnus.com
[ mailto:owner-gnu-win32@cygnus.com]On
> > Behalf Of Earnie Boyd
> > Sent: Wednesday, November 11, 1998 5:23 AM
> > To: Laurent Charles; gnu-win32
> > Subject: Re: cygpath
> >
> >
> > ---Laurent Charles <laurent.charles@st.com> wrote:
> > >
> > > Hello,
> > >
> > > When I use cygpath as follows;
> > >  cygpath -w "/usr/local/bin/tool -f /usr/src/source.c"
> > > It replies;
> > >  U:\local\bin\tool -f \usr\src\source.c
> > >
> >
> > What is the -f option?  cygpath --help only shows -w, -u and -p
> >
> >
> >
> > ==
> > -                  \\||//
> > -------------o0O0--Earnie--0O0o--------------
> > --          earnie_boyd@yahoo.com          --
> > -- http://www.freeyellow.com/members5/gw32 --
> > ----------------ooo0O--O0ooo-----------------
> >
> > PS: Newbie's, you should visit my page.
> > _________________________________________________________
> > DO YOU YAHOO!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> > -
> > For help on using this list (especially unsubscribing), send a
message to
> > "gnu-win32-request@cygnus.com" with one line of text: "help".
> >
> 
> 

==
-                  \\||//
-------------o0O0--Earnie--0O0o--------------
--          earnie_boyd@yahoo.com          --
-- http://www.freeyellow.com/members5/gw32 --
----------------ooo0O--O0ooo-----------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: cygpath

[Rick Rankin]

> 
> What happens if you write it this way:
> 
> BASH$ /usr/local/bin/tool -f `cygpath -w /usr/src/source.c`
> 

Actually, that's very close to what I suggested, which was

/usr/local/bin/tool -f $(cygpath -w /usr/src/source.c)

Both will work fine.

--
Rick Rankin
rrankin@primenet.com 


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: cygpath

[Laurent Charles]

Thank you everybody for your replies about cygpath.

earnie_boyd@yahoo.com wrote:
> What is wrong with executing tool with the suggestions you received
> earlier?
Everything is fine with all that (I guess, I didn't check them all). I
just wanted to use cygpath a way it can not work. 

> IMHO, cygpath is fine the way it is.
Ok. I also realized that there may be some problems to have cygpath
dealing with spaces in filenames (eg: Program Files) if it considers its
parameters as a full command line.

--Laurent
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: cygpath

[Joshua Daniel Franklin]

--- Dave Yost wrote:
> Thanks for cygpath and whaterver you do for cygwin!

Dave, 

While I have submitted a couple patches to cygpath, a lot of people have put
work into it and I certainly can't take credit for the whole thing! Several
of these people and other knowledgable cygwin users are on the Cygwin list,
so it would be better to keep questions on the list.

> I have a small problem.
> 
> I have a path ../foo:../bar
> 
> When I use the --path argument, cygpath insists on converting the relative
> paths into absolute paths.  I wish it wouldn't do that.  But I can understand
> the need for backward compatibility, so could I request a --relative option?

You might use a simple sed script to take out what you don't need.

> Also:
> 
> I have this nasty problem with the Sun 1.4.x JDK (fixed in 1.5.0-beta1).  I
> pass in a classpath argument like this:
> 
> javac -classpath `cygpath -w /usr/local/jdk/lib/tools.jar` X.java
> 
> Problem is, /usr/local/jdk is a cygwin symlink, and the java runtime
> apparently can't follow symbolic links or shortcuts.

I don't use Java with cygwin, so maybe someone else on the list will have 
some ideas for this issue.

> It would be cool if cygpath had an option to resolve any symlinks and
> shortcuts in the path.

Yes, it would. Patches thankfully accepted. :)


	
		
__________________________________
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861 

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

RE: cygpath

[Dave Korn]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Joshua Daniel Franklin
> Sent: 12 May 2004 17:22

> > It would be cool if cygpath had an option to resolve any 
> symlinks and
> > shortcuts in the path.
> 
> Yes, it would. Patches thankfully accepted. :)

  Don't you mean "Patches gratefully considered" ?!  :P


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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

Re: cygpath

[Christopher Faylor]

On Wed, May 12, 2004 at 09:21:36AM -0700, Joshua Daniel Franklin wrote:
>>It would be cool if cygpath had an option to resolve any symlinks and
>>shortcuts in the path.
>
>Yes, it would.  Patches thankfully accepted.  :)

I don't see this as a function of cygpath.  cygpath is for performing
operations on the windows environment.  Having it resolve symlinks is
outside of that scope.  You can use regular UNIX-like tools to do that.

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/

Re: cygpath

[Igor Pechtchanski]

On Wed, 12 May 2004, Joshua Daniel Franklin wrote:

> --- Dave Yost wrote:
> [snip]
> > I have a small problem.
> >
> > I have a path ../foo:../bar
> >
> > When I use the --path argument, cygpath insists on converting the relative
> > paths into absolute paths.  I wish it wouldn't do that.  But I can understand
> > the need for backward compatibility, so could I request a --relative option?
>
> You might use a simple sed script to take out what you don't need.

Keeping relative paths might actually be useful functionality in cygpath.
<http://cygwin.com/acronyms/#PTC>.

> > Also:
> >
> > I have this nasty problem with the Sun 1.4.x JDK (fixed in 1.5.0-beta1).  I
> > pass in a classpath argument like this:
> >
> > javac -classpath `cygpath -w /usr/local/jdk/lib/tools.jar` X.java
> >
> > Problem is, /usr/local/jdk is a cygwin symlink, and the java runtime
> > apparently can't follow symbolic links or shortcuts.
>
> I don't use Java with cygwin, so maybe someone else on the list will have
> some ideas for this issue.

Use mounts instead of symlinks.  Alternatively, you can take the java
wrapper script I posted to this list some time ago[*], and modify it to
walk the classpath and resolve symlinks.
	Igor
[*] <http://cygwin.com/ml/cygwin/2003-01/msg00174.html> or use the CVS
version at :pserver:anoncvs@sources.redhat.com:/cvs/cygwin-apps (directory
wrappers/java).
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

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

cygpath

[Jim P]

I just updated my cygwin install, and cygpath appears to be broken.  Issuing the
command "cygpath", with any or no command-line options, returns nothing and a
status of 127.


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

Re: cygpath

[Edward Lam]

On 3/2/2011 9:05 AM, Jim P wrote:
> I just updated my cygwin install, and cygpath appears to be broken.  Issuing the
> command "cygpath", with any or no command-line options, returns nothing and a
> status of 127.

But other commands work? eg. ls ... If you've rebased your cygwin 
install in the past, then you might need to rebase again. I'd also do a 
reboot but that's just paranoid me.

-Edward

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

Re: cygpath

[Roger K. Wells]

On 03/02/2011 09:05 AM, Jim P wrote:
> I just updated my cygwin install,
so did I (an hour ago)
>   and cygpath appears to be broken.  Issuing the
> command "cygpath", with any or no command-line options, returns nothing and a
> status of 127.
>
cygpath works as expected
roger wells
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>


-- 
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells@saic.com


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

cygpath

[Gluszczak, Glenn]

Isn’t this a defect in cygpath?  Looks like memory corruption.


%%%cygpath -w /usr/tmp/*
C:\cygwin\usr\tmp\

%%%cygpath -w /usr/non-existent/*
C:\cygwin\usr\non-existent\�[W��\x03



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

Re: cygpath

[Andrey Repin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 692 bytes --]

Greetings, Gluszczak, Glenn!

> Isn’t this a defect in cygpath?  Looks like memory corruption.

> %%%cygpath -w /usr/non-existent/*
> C:\cygwin\usr\non-existent\�[W��\x03

Looks more like private character space combined with incorrect terminal setup.

See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars


-- 
With best regards,
Andrey Repin
Friday, February 10, 2017 22:33:18

Sorry for my terrible english...\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ˜\KÃB‘^[ØÝ[Y[\x18]\x1a[ÛŽˆ\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ^[ØÜËš\x1d^[[\x03B•[œÝXœØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB

RE: cygpath

[Gluszczak, Glenn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1258 bytes --]

* is a legal character for ls but perhaps not cygpath?  I don't know.
No files or directories are using * in the name. 

Not sure about incorrect terminal settings as I never touched any.  
It shows up in mintty and ssh equally. The characters that appear vary.

Some non-existent paths do *not* produce the gibberish.

%%%cygpath -w /aaa/bbb/*
C:\cygwin\aaa\bbb\



-----Original Message-----
From: Andrey Repin [mailto:anrdaemon@yandex.ru] 
Sent: Friday, February 10, 2017 2:36 PM
To: Gluszczak, Glenn; cygwin@cygwin.com
Subject: Re: cygpath

Greetings, Gluszczak, Glenn!

> Isn’t this a defect in cygpath?  Looks like memory corruption.

> %%%cygpath -w /usr/non-existent/*
> C:\cygwin\usr\non-existent\�[W��\x03

Looks more like private character space combined with incorrect terminal setup.

See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars


-- 
With best regards,
Andrey Repin
Friday, February 10, 2017 22:33:18

Sorry for my terrible english...
\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ

RE: cygpath

[Gluszczak, Glenn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1606 bytes --]

Sorry, I forgot the user I log in as is switching to cmd.exe.

This doesn't happen in sh or tcsh, so it is probably a non-issue.



-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Gluszczak, Glenn
Sent: Friday, February 10, 2017 3:04 PM
To: cygwin@cygwin.com
Subject: RE: cygpath

* is a legal character for ls but perhaps not cygpath?  I don't know.
No files or directories are using * in the name. 

Not sure about incorrect terminal settings as I never touched any.  
It shows up in mintty and ssh equally. The characters that appear vary.

Some non-existent paths do *not* produce the gibberish.

%%%cygpath -w /aaa/bbb/*
C:\cygwin\aaa\bbb\



-----Original Message-----
From: Andrey Repin [mailto:anrdaemon@yandex.ru] 
Sent: Friday, February 10, 2017 2:36 PM
To: Gluszczak, Glenn; cygwin@cygwin.com
Subject: Re: cygpath

Greetings, Gluszczak, Glenn!

> Isn’t this a defect in cygpath?  Looks like memory corruption.

> %%%cygpath -w /usr/non-existent/*
> C:\cygwin\usr\non-existent\�[W��\x03

Looks more like private character space combined with incorrect terminal setup.

See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars


-- 
With best regards,
Andrey Repin
Friday, February 10, 2017 22:33:18

Sorry for my terrible english...
\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ

Re: cygpath

[Michael Enright]

On Fri, Feb 10, 2017 at 12:31 PM, Gluszczak, Glenn wrote:
> Sorry, I forgot the user I log in as is switching to cmd.exe.
>
> This doesn't happen in sh or tcsh, so it is probably a non-issue.
>

My results are from running a "normal" bash-under-mintty setup.

If I go to a cmd.exe window and start bash,

Z:\>cygpath -w "/usr/bin/*"
C:\cygwin\bin\?

Z:\>

This is consistent with the explanation that an asterisk ends up
having a private-use character substituted in for it.

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

Re: cygpath

[Michael Enright]

On Fri, Feb 10, 2017 at 12:42 PM, Michael Enright wrote:
> On Fri, Feb 10, 2017 at 12:31 PM, Gluszczak, Glenn wrote:
>> Sorry, I forgot the user I log in as is switching to cmd.exe.
>>
>> This doesn't happen in sh or tcsh, so it is probably a non-issue.
>>
>
> My results are from running a "normal" bash-under-mintty setup.
>
> If I go to a cmd.exe window and start bash,
>
Correction. I simply put c:/cygwin/bin on my path I didn't start bash.
[redfaced emoji]

> Z:\>cygpath -w "/usr/bin/*"
> C:\cygwin\bin\?
>
> Z:\>
>
The result when I really did go into bash was basically identical (the
character rendered as a question mark, which is the expected
rendering).

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

RE: cygpath

[Gluszczak, Glenn]

Thanks for the explanation.  Just odd how cmd.exe only sometimes misbehaves.

%%%cygpath -w /usr/a/b/*
C:\cygwin\usr\a\b\

%%%cygpath -w /a/b/*
C:\cygwin\a\b\

%%%cygpath -w /a/b/c/*
C:\cygwin\a\b\c\\x15


-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Michael Enright
Sent: Friday, February 10, 2017 3:43 PM
To: cygwin@cygwin.com
Subject: Re: cygpath

On Fri, Feb 10, 2017 at 12:31 PM, Gluszczak, Glenn wrote:
> Sorry, I forgot the user I log in as is switching to cmd.exe.
>
> This doesn't happen in sh or tcsh, so it is probably a non-issue.
>

My results are from running a "normal" bash-under-mintty setup.

If I go to a cmd.exe window and start bash,

Z:\>cygpath -w "/usr/bin/*"
C:\cygwin\bin\?

Z:\>

This is consistent with the explanation that an asterisk ends up having a private-use character substituted in for it.

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


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

Re: cygpath

[Andrey Repin]

Greetings, Gluszczak, Glenn!

> * is a legal character for ls but perhaps not cygpath?

"*" is not a legal path name character. And cygpath expects a path.

> I don't know.
> No files or directories are using * in the name. 

See above.

> Not sure about incorrect terminal settings as I never touched any.  
> It shows up in mintty and ssh equally. The characters that appear vary.

For me, it shows a single blank box character. (The required character is
missing from the font I'm using in mintty.)

> Some non-existent paths do *not* produce the gibberish.

> %%%cygpath -w /aaa/bbb/*
> C:\cygwin\aaa\bbb\

Works equally for me.

$ cygpath -w /usr/non-existent/* | od -t x1
0000000 43 3a 5c 50 72 6f 67 72 61 6d 73 5c 43 79 67 77
0000020 69 6e 5f 36 34 5c 75 73 72 5c 6e 6f 6e 2d 65 78
0000040 69 73 74 65 6e 74 5c ef 80 aa 0a
0000053

$ cygpath -w /aaa/bbb/* | od -t x1
0000000 43 3a 5c 50 72 6f 67 72 61 6d 73 5c 43 79 67 77
0000020 69 6e 5f 36 34 5c 61 61 61 5c 62 62 62 5c ef 80
0000040 aa 0a
0000042

Also please don't top-post https://cygwin.com/acronyms/#TOFU and don't quote
raw email addresses. https://cygwin.com/lists.html


-- 
With best regards,
Andrey Repin
Saturday, February 11, 2017 00:27:02

Sorry for my terrible english...


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

RE: cygpath

[Gluszczak, Glenn]

I suppose the glob explanation from Michael explains this behavior in sh.
Though unsupported, it seems to work (probably some side cases do not).

$ cygpath -w /usr/bin/*
C:\cygwin64\bin\[.exe
C:\cygwin64\bin\2to3
C:\cygwin64\bin\addftinfo.exe
C:\cygwin64\bin\addr2line.exe
C:\cygwin64\bin\whatis.exe
C:\cygwin64\bin\ar.exe
C:\cygwin64\bin\arch.exe
C:\cygwin64\bin\as.exe
C:\cygwin64\bin\ash.exe
C:\cygwin64\bin\gawk.exe
C:\cygwin64\bin\b2sum.exe
....



-----Original Message-----

Greetings, Gluszczak, Glenn!

> * is a legal character for ls but perhaps not cygpath?

"*" is not a legal path name character. And cygpath expects a path.

> I don't know.
> No files or directories are using * in the name. 

See above.

> Not sure about incorrect terminal settings as I never touched any.  
> It shows up in mintty and ssh equally. The characters that appear vary.

For me, it shows a single blank box character. (The required character is missing from the font I'm using in mintty.)

> Some non-existent paths do *not* produce the gibberish.

> %%%cygpath -w /aaa/bbb/*
> C:\cygwin\aaa\bbb\

Works equally for me.

$ cygpath -w /usr/non-existent/* | od -t x1
0000000 43 3a 5c 50 72 6f 67 72 61 6d 73 5c 43 79 67 77
0000020 69 6e 5f 36 34 5c 75 73 72 5c 6e 6f 6e 2d 65 78
0000040 69 73 74 65 6e 74 5c ef 80 aa 0a
0000053

$ cygpath -w /aaa/bbb/* | od -t x1
0000000 43 3a 5c 50 72 6f 67 72 61 6d 73 5c 43 79 67 77
0000020 69 6e 5f 36 34 5c 61 61 61 5c 62 62 62 5c ef 80
0000040 aa 0a
0000042

Also please don't top-post https://cygwin.com/acronyms/#TOFU and don't quote raw email addresses. https://cygwin.com/lists.html


--
With best regards,
Andrey Repin
Saturday, February 11, 2017 00:27:02

Sorry for my terrible english...


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

Re: cygpath

[Michael Enright]

On Fri, Feb 10, 2017 at 1:46 PM, Gluszczak, Glenn wrote:
> I suppose the glob explanation from Michael explains this behavior in sh.
> Though unsupported, it seems to work (probably some side cases do not).

It seems to me that the behavior is supported and working. Bash or sh
takes an unescaped argument /usr/bin/* and expands it to a list of
names, which it provides as an array of arguments to the called
program, cygpath in this case. Then cygpath converts each and outputs
each result. If the user escapes the argument in someway, the asterisk
survives and is treated as a Unix file name character. If there is no
glob expansion, in the case of the unescaped argument
/usr/nonexistent/* for example, Bash only passes one argument, and the
asterisk in that is treated as a filename character.

I think when the output to your terminal is weird, it is because of
locale settings or code pages that either hide or garble the output of
the unicode character. When the output is piped to od as Andre does,
the output is clearly the UTF8 byte sequence for U+F02A.

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

Re: cygpath

[Michael Enright]

On Fri, Feb 10, 2017 at 1:34 PM, Andrey Repin wrote:
> Greetings, Gluszczak, Glenn!
>
>> * is a legal character for ls but perhaps not cygpath?
>
> "*" is not a legal path name character. And cygpath expects a path.

AFAICT, '*' is a legal character in a filename or directory name on
Posix systems and Linux.
Source:
https://en.wikipedia.org/wiki/Filename#Reserved_characters_and_words

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

Re: cygpath

[Eliot Moss]

On 2/10/2017 3:03 PM, Gluszczak, Glenn wrote:
> * is a legal character for ls but perhaps not cygpath?  I don't know.
> No files or directories are using * in the name.
>
> Not sure about incorrect terminal settings as I never touched any.
> It shows up in mintty and ssh equally. The characters that appear vary.
>
> Some non-existent paths do *not* produce the gibberish.
>
> %%%cygpath -w /aaa/bbb/*
> C:\cygwin\aaa\bbb\

Yes, but I found something interesting when I did this:

echo "$(cygpath -w /usr/non-existent/*)" > mytemp

od -c mytemp

revealed that there is a three-byte sequence after the
output of

C:\cygwin\usr\non-existent\

and before the newline added by echo.  I guess it's
some representation of * that does not show up on the
terminal, but it did strike me as a little strange ...

Regards - EM

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

Re: cygpath

[Sam Edge]

On 10/02/2017 23:17, Eliot Moss wrote:
> On 2/10/2017 3:03 PM, Gluszczak, Glenn wrote:
>> * is a legal character for ls but perhaps not cygpath?  I don't know.
>> No files or directories are using * in the name.
>>
>> Not sure about incorrect terminal settings as I never touched any.
>> It shows up in mintty and ssh equally. The characters that appear vary.
>>
>> Some non-existent paths do *not* produce the gibberish.
>>
>> %%%cygpath -w /aaa/bbb/*
>> C:\cygwin\aaa\bbb\
>
> Yes, but I found something interesting when I did this:
>
> echo "$(cygpath -w /usr/non-existent/*)" > mytemp
>
> od -c mytemp
>
> revealed that there is a three-byte sequence after the
> output of
>
> C:\cygwin\usr\non-existent\
>
> and before the newline added by echo.  I guess it's
> some representation of * that does not show up on the
> terminal, but it did strike me as a little strange ...
>
> Regards - EM
>
> -- 
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>
Sorry, did anyone actually read Andrey's post?

(Hint: Read
https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars
again.)

The three byte sequence is the UTF-8 representation of U+F02A i.e. ASCII
for '*' but in the private use area of Unicode.

This is how the Cygwin DLL stores ASCII characters in pathnames that are
forbidden in Windows but that are valid in POSIX. The directory entry
write functions convert them to private area and the read functions
convert them back to Unicode.

The cygpath utility therefore does exactly the same on the assumption
that the result is going to be passed to Windows programs that are going
to manipulate the directory entry in some way - open the file for example.

That they display incorrectly is an inevitable side effect of this
work-around.

Generally, all you need to do is accept the Copenhagen interpretation in
your scripts and just calculate. ;-)

The only thing you need to be careful of is that if you really mean to
pass the glob to your Windows app, you leave it out of the string passed
to cygpath e.g.

cygstart some-exe "$(cygpath -w "some-posix-path/")"\*

instead of

cygstart some-exe "$(cygpath -w "some-posix-path/*")"


-- 
Sam Edge


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

Re: cygpath

[Eliot Moss]

On 2/10/2017 6:50 PM, Sam Edge wrote:

> Sorry, did anyone actually read Andrey's post?

Yes, but I was going through the emails in order and responded
to the earlier one before I got to the later one.  Sorry to have
added noise to the list ...

EM

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

Re: cygpath

[Sam Edge]

On 11/02/2017 00:05, Eliot Moss wrote:
> On 2/10/2017 6:50 PM, Sam Edge wrote:
>
>> Sorry, did anyone actually read Andrey's post?
>
> Yes, but I was going through the emails in order and responded
> to the earlier one before I got to the later one.  Sorry to have
> added noise to the list ...
>
No prob. Perhaps a little over-exasperated here. sorry. Not an excuse
but it's been a long week!

Off to watch Tucker and Dale ... :-)

-- 
Sam Edge


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

Re: cygpath

[Michael Enright]

On Fri, Feb 10, 2017 at 11:36 AM, Andrey Repin  wrote:
> Greetings, Gluszczak, Glenn!
>
>> Isn’t this a defect in cygpath?  Looks like memory corruption.
>
>> %%%cygpath -w /usr/non-existent/*
>> C:\cygwin\usr\non-existent\�[W��
>
> Looks more like private character space combined with incorrect terminal setup.

The link to private character space is realllly obscure. Firstly, the
commands that sometimes show failure have a '*' or splat in them. Bash
will try to convert a path with a splat in it to the list of matching
paths, if there are matches. If there aren't, then the argument seen
by the spawned program will contain a splat. Then the cygpath program
has to properly describe the path that contains the splat. The splat
is not a legal character IN A WINDOWS PATH, but a private character
could be and that's how terminal configuration enters in. Cygpath is
giving the string that would be used to represent the path, and that
string will contain a private use character.

In my testing, the environment has no LC variable set to anything, so
the locale mechanisms are presumably doing their default things. All
my attempts with this got a empty box character at first, if the
asterisk went through. That empty box character is presumably some
private use character that is supposed to substitute for an asterisk.
When I switched mintty's configuration to use Consolas, the
previously-run tests output was rerendered by mintty and the 'bad'
character rendered as a box with a question mark inside.

If I enter cygpath -w /usr/bin/* I get output consisting of all the
files in /usr/bin with their paths converted to Windows form. If I
escape the argument so globbing is not done, I get the strange output.

 cygpath -w '/usr/bin/*'
C:\cygwin\bin\

In the above the ticks around the path prevented the path from being
globbed. It might be considered unexpected though, that the path with
an asterisk would be treated as "The user desired to know what the
windows path to a file would be if it's cygwin path ended with an
asterisk". I think the odds of that user story are vanishingly small
compared to the odds of "What would a Windows path to a wildcard look
like that corresponds to this Cygwin wildcard?" But that's a design
problem.

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

RE: cygpath

[Nellis, Kenneth (Conduent)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1060 bytes --]

From: Andrey Repin 
> See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars

This reference says:

> All of the above characters, except for the backslash, are converted to 
> special UNICODE characters in the range 0xf000 to 0xf0ff (the "Private 
> use area") when creating or accessing files.

It does not say *how* they are converted. In fact, by observation, 
they appear to be converted by having 0xF000 added to their code points.
Perhaps this text could be updated accordingly.

I propose the following:

> All of the above characters, except for the backslash, are converted to 
> special UNICODE characters in the range 0xf000 to 0xf0ff (the "Private 
> use area") when creating or accessing files by adding 0xf000 to the
> forbidden characters' code points.

--Ken Nellis
\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ

Re: cygpath

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

On Feb 13 17:29, Nellis, Kenneth (Conduent) wrote:
> From: Andrey Repin 
> > See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars
> 
> This reference says:
> 
> > All of the above characters, except for the backslash, are converted to 
> > special UNICODE characters in the range 0xf000 to 0xf0ff (the "Private 
> > use area") when creating or accessing files.
> 
> It does not say *how* they are converted. In fact, by observation, 
> they appear to be converted by having 0xF000 added to their code points.
> Perhaps this text could be updated accordingly.
> 
> I propose the following:
> 
> > All of the above characters, except for the backslash, are converted to 
> > special UNICODE characters in the range 0xf000 to 0xf0ff (the "Private 
> > use area") when creating or accessing files by adding 0xf000 to the
> > forbidden characters' code points.

Patched.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: cygpath

[Nellis, Kenneth (Conduent)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 655 bytes --]

From: Corinna Vinschen
> On Feb 13 17:29, Nellis, Kenneth (Conduent) wrote:
> > From: Andrey Repin
> > > See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars
> >
> > This reference says:
> > ...
> > I propose the following:
> > ...
> 
> Patched.

Thanx for that, but not sure what "Patched" means in this context.
In any case, I don't see the change to the web page.

--Ken Nellis
\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ

Re: cygpath

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On Feb 15 14:41, Nellis, Kenneth (Conduent) wrote:
> From: Corinna Vinschen
> > On Feb 13 17:29, Nellis, Kenneth (Conduent) wrote:
> > > From: Andrey Repin
> > > > See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars
> > >
> > > This reference says:
> > > ...
> > > I propose the following:
> > > ...
> > 
> > Patched.
> 
> Thanx for that, but not sure what "Patched" means in this context.
> In any case, I don't see the change to the web page.

Docs are in git, patch pushed.  The website will catch up eventually...

...make that "now".  I actually forgot to upload the 2.7.0 docs.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: cygpath

[Brian Inglis]

On 2017-02-10 12:07, Gluszczak, Glenn wrote:
> Isn’t this a defect in cygpath?  Looks like memory corruption.
> %%%cygpath -w /usr/tmp/*
> C:\cygwin\usr\tmp\
> %%%cygpath -w /usr/non-existent/*
> C:\cygwin\usr\non-existent\�[W��\x03

For proper interpretation of a Unix path name, all but the last component must
exist, and that is expected to be a file system entry which will be created.

Unix wild cards are looked up and expanded by the shell prior to command 
execution, so are expected to be existing path names used as input to a 
command, otherwise they are passed to the command as is: if used as an input 
path name, it should not exist; if used as an output path name, it will be 
created if all but the last component exist, otherwise it should fail as a 
directory component in the path does not exist.

One exception is mkdir -p, and there may be some similar commands which will
create multiple explicit directory tree entries in a path.

AFAIK there are no Unix commands which allow output wild card path names and 
interpret them as being the same as the input names, but there are some cmd 
shell commands which allow or expect this e.g. RENAME *.bat *.cmd, which on 
Unix has to be done with multiple commands in a a loop e.g.

	for bat in *.bat; do mv $bat ${bat%.bat}.cmd; done

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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