Re: Windows-style pathname does not work as command - why?
on Thu, 02 Sep 2010 12:13:12 -0600, Eric Blake 4c7fe938.6060...@redhat.com
attacked their terminal with
[stuff relating to Win32 paths]
Here's a sed script I use to get around that... Put this in your script (or
~/.bashrc) and enjoy
function wintocyg {
if [ x${$1} == x ]; then
return 1
fi
echo $1 | sed 's/\([a-zA-Z]\)\:/\/cygdrive\/\1/g;s:\\:/:g'
}
This:
- checks that there is an argument.
- Converts that argument using a sed script that looks for a drive letter, :\
and converts that into a Cygdrive path. This works for root level stuff
(d:\) and for deeply nested things (like d:\ping\me_with\a hundred boxes
of\liquor).
Pretty Simple Stuff, but its a pain. I've used this for a while now.
I know its a hack but its /works/. You could easily make it escape ' '* but I'm
assuming you're calling it using `wintocyg mypath` ( /always/ escape your
paths )
* that would be done by taking and actually wrapping the entire function around
an echo statement like « echo \`echo $1 ...`\ »
--
Morgan Gangwere
Key ID A8B6F243, available from MIT.
BOFH excuse #441:
Hash table has woodworm
signature.asc
Description: PGP signature
Re: Windows-style pathname does not work as command - why?
On 9/9/2010 11:20 AM, Morgan Gangwere wrote:
on Thu, 02 Sep 2010 12:13:12 -0600, Eric Blake 4c7fe938.6060...@redhat.com
attacked their terminal with
[stuff relating to Win32 paths]
Here's a sed script I use to get around that... Put this in your script (or
~/.bashrc) and enjoy
function wintocyg {
if [ x${$1} == x ]; then
return 1
fi
echo $1 | sed 's/\([a-zA-Z]\)\:/\/cygdrive\/\1/g;s:\\:/:g'
}
This:
- checks that there is an argument.
- Converts that argument using a sed script that looks for a drive letter, :\
and converts that into a Cygdrive path. This works for root level stuff
(d:\) and for deeply nested things (like d:\ping\me_with\a hundred boxes
of\liquor).
Pretty Simple Stuff, but its a pain. I've used this for a while now.
I know its a hack but its /works/. You could easily make it escape ' '* but
I'm
assuming you're calling it using `wintocyg mypath` ( /always/ escape your
paths )
Actually, this function only works if the user has the default cygdrive
prefix. This can and often *is* changed, however. Fortunately, the
Cygwin developers have had your back on this for a very long time. Use
the cygpath program to convert all your paths. It safely handles
conversions both to and from POSIX for both absolute and relative paths,
can convert to short form DOS paths (e.g C:\Progra~1\...), supports
paths with arbitrary whitespace, can provide many well known paths such
as the user's Desktop directory, can be run by Windows-native programs,
and more.
-Jeremy
--
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: Windows-style pathname does not work as command - why?
on Thu, 09 Sep 2010 13:50:08 -0500, Jeremy Bopp 4c892c60.6040...@bopp.net attacked their terminal with +Actually, this function only works if the user has the default cygdrive +prefix. This can and often *is* changed, however. Fortunately, the +Cygwin developers have had your back on this for a very long time. Use +the cygpath program to convert all your paths. It safely handles +conversions both to and from POSIX for both absolute and relative paths, +can convert to short form DOS paths (e.g C:\Progra~1\...), supports +paths with arbitrary whitespace, can provide many well known paths such +as the user's Desktop directory, can be run by Windows-native programs, +and more. how do you change the default cygdrive path? I figured it was a set-in-stone kindof thing. -- Morgan Gangwere Key ID A8B6F243, available from MIT. BOFH excuse #81: Please excuse me, I have to circuit an AC line through my head to get this database working. signature.asc Description: PGP signature
Re: Windows-style pathname does not work as command - why?
On 9/9/2010 2:27 PM, Morgan Gangwere wrote: on Thu, 09 Sep 2010 13:50:08 -0500, Jeremy Bopp 4c892c60.6040...@bopp.net attacked their terminal with +Actually, this function only works if the user has the default cygdrive +prefix. This can and often *is* changed, however. Fortunately, the +Cygwin developers have had your back on this for a very long time. Use +the cygpath program to convert all your paths. It safely handles +conversions both to and from POSIX for both absolute and relative paths, +can convert to short form DOS paths (e.g C:\Progra~1\...), supports +paths with arbitrary whitespace, can provide many well known paths such +as the user's Desktop directory, can be run by Windows-native programs, +and more. how do you change the default cygdrive path? I figured it was a set-in-stone kindof thing. Add something like the following line to your /etc/fstab file and restart all your Cygwin processes: none / cygdrive binary,posix=0,noacl,user 0 0 This example will set your cygdrive prefix to simply be /, so you can access the C: drive via /c/whatever. More details are available in the user guide: http://cygwin.com/cygwin-ug-net/using.html#mount-table -Jeremy -- 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: Windows-style pathname does not work as command - why?
Larry Hall (Cygwin) wrote: On 9/8/2010 1:24 PM, Andy Koppe wrote: On 8 September 2010 17:35, Larry Hall (Cygwin) wrote: Isn't the whole reason for Cygwin actually to enable doing Unixy things in Windows (that is, providing Windows/Unix interoperablity? No, that's not a key goal. From the Cygwin main web page: Cygwin is a Linux-like environment for Windows Well, I (and my employer) would not be using Cygwin if it wasn't for the Windows integration, in particular the ability to plug POSIX and Windows programs together. If I just wanted to run Linux software on Windows, I'd use a virtual machine or coLinux. While Cygwin's lower resource usage is nice to have, that's easily outweighed by the inevitable compatibility and performance drawbacks that come with building on top of Win32. There are allot of different reasons people choose to use Cygwin. However, as a product (and I'm not suggesting anything commercially motivated here when using that term), it has some key design goals. They are the ones I quoted from the main page on the Cygwin web site. There are others that are secondary goals. Interoperability is certainly one. But Windows/DOS-style path support is not the whole reason for Cygwin as the OP suggested. I did NOT say that Windows/DOS-style path support was the whole reason for Cygwin. Pay attention to your quoting/paraphrasing. It is, rather, a case where the primary goals of Linux compatibility require a choice to be made and in this case the choice is POSIX-style paths trump Windows/DOS-style paths anywhere the support cost is too high for the latter. The general argument of Windows interoperability in Cygwin has been discussed on the list in the past. I'm not trying to re-open those threads or start a new flame war on the subject. I'm only trying to correct a misconception of the OP with regards to accepted path syntax. I hope that's clear now. Not yet. Cygpath certainly supports Windows-style paths. Are you claiming that places like that are the only place that it is accepted to use Windows-styles paths (that is, if something like ls 'C:\x\y' quit working, it likely wouldn't be fixed)? Daniel -- 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: Windows-style pathname does not work as command - why?
Date: Thu, 9 Sep 2010 16:56:37 -0400 From: daniel To: cygwin Subject: Re: Windows-style pathname does not work as command - why? Not yet. Cygpath certainly supports Windows-style paths. Are you claiming that places like that are the only place that it is accepted to use Windows-styles paths (that is, if something like ls 'C:\x\y' quit working, it likely wouldn't be fixed)? I'm answering more generally than just ls. Everything is ultimately on a case by case basis. If it stops working because of a conflict with an important posixy thing, then it is likely gone. If it just stops working because of an update to some package, then if someone (the package maintainer or some motivated user) wants it fixed, it can be fixed. But clearly SHTDI. I think that it is time for this thread to move to the cygwin talk list. Thanks, ...Karl -- 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: Windows-style pathname does not work as command - why?
Christopher Faylor wrote: On Thu, Sep 02, 2010 at 12:13:12PM -0600, Eric Blake wrote: On 09/02/2010 11:45 AM, Daniel Barclay wrote: I don't quite understand this behavior: $ ls C:\\tools\\emacs-23.2\\bin\\runemacs.exe C:\tools\emacs-23.2\bin\runemacs.exe $ C:\\tools\\emacs-23.2\\bin\\runemacs.exe bash: C:\tools\emacs-23.2\bin\runemacs.exe: command not found In particular, why is it that bash does not understand that Windows pathname when it is used as a command argument, even though bash and Cygwin clearly understand it when it is used as a command argument? Is that behavior a bug (e.g., does bash try to judge whether the command is an absolute vs. relative pathname without either first converting to a Unix-style pathname or otherwise recognizing Windows-style pathname)? You're not the first to notice this, but it's also not the highest priority on my list to look into, because we already recommend using POSIX style paths in the first place. Or is it some known irregularity (resulting from trying to handle both Windows- and Unix-style pathnames) that couldn't be resolved? Oh, I'm sure that bash could be patched to be smarter about DOS-style pathnames. But no one has been bothered by it enough to write a patch yet. And, trying hard to make MS-DOS stuff work is sorta counter to the whole reason for Cygwin. Isn't the whole reason for Cygwin actually to enable doing Unixy things in Windows (that is, providing Windows/Unix interoperablity? Also, to clarify: I didn't mean DOS-specific pathnames, as opposed to general Windows pathname (e.g., meaning 8.3-style vs. VFAT long names). I just meant DOS-/Windows-style pathnames (as opposed to Unix-style pathnames). Daniel Daniel cgf -- 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: Windows-style pathname does not work as command - why?
On 9/8/2010 11:58 AM, Daniel Barclay wrote: Christopher Faylor wrote: snip And, trying hard to make MS-DOS stuff work is sorta counter to the whole reason for Cygwin. Isn't the whole reason for Cygwin actually to enable doing Unixy things in Windows (that is, providing Windows/Unix interoperablity? No, that's not a key goal. From the Cygwin main web page: Cygwin is a Linux-like environment for Windows. It consists of two parts: # A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality. # A collection of tools which provide Linux look and feel. So, since Linux doesn't support Windows path syntax, it's not a goal for Cygwin to be able to do it either. That's not to say that Cygwin won't support it. Just that if it's hard to make it work in all cases, then the result will likely be that those cases just don't work unless you use POSIX-style paths. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Windows-style pathname does not work as command - why?
On 8 September 2010 17:35, Larry Hall (Cygwin) wrote: Isn't the whole reason for Cygwin actually to enable doing Unixy things in Windows (that is, providing Windows/Unix interoperablity? No, that's not a key goal. From the Cygwin main web page: Cygwin is a Linux-like environment for Windows Well, I (and my employer) would not be using Cygwin if it wasn't for the Windows integration, in particular the ability to plug POSIX and Windows programs together. If I just wanted to run Linux software on Windows, I'd use a virtual machine or coLinux. While Cygwin's lower resource usage is nice to have, that's easily outweighed by the inevitable compatibility and performance drawbacks that come with building on top of Win32. Andy -- 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: Windows-style pathname does not work as command - why?
On 9/8/2010 1:24 PM, Andy Koppe wrote: On 8 September 2010 17:35, Larry Hall (Cygwin) wrote: Isn't the whole reason for Cygwin actually to enable doing Unixy things in Windows (that is, providing Windows/Unix interoperablity? No, that's not a key goal. From the Cygwin main web page: Cygwin is a Linux-like environment for Windows Well, I (and my employer) would not be using Cygwin if it wasn't for the Windows integration, in particular the ability to plug POSIX and Windows programs together. If I just wanted to run Linux software on Windows, I'd use a virtual machine or coLinux. While Cygwin's lower resource usage is nice to have, that's easily outweighed by the inevitable compatibility and performance drawbacks that come with building on top of Win32. There are allot of different reasons people choose to use Cygwin. However, as a product (and I'm not suggesting anything commercially motivated here when using that term), it has some key design goals. They are the ones I quoted from the main page on the Cygwin web site. There are others that are secondary goals. Interoperability is certainly one. But Windows/DOS-style path support is not the whole reason for Cygwin as the OP suggested. It is, rather, a case where the primary goals of Linux compatibility require a choice to be made and in this case the choice is POSIX-style paths trump Windows/DOS-style paths anywhere the support cost is too high for the latter. The general argument of Windows interoperability in Cygwin has been discussed on the list in the past. I'm not trying to re-open those threads or start a new flame war on the subject. I'm only trying to correct a misconception of the OP with regards to accepted path syntax. I hope that's clear now. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Windows-style pathname does not work as command - why?
On Wed, Sep 08, 2010 at 02:47:57PM -0400, Larry Hall (Cygwin) wrote: On 9/8/2010 1:24 PM, Andy Koppe wrote: On 8 September 2010 17:35, Larry Hall (Cygwin) wrote: Isn't the whole reason for Cygwin actually to enable doing Unixy things in Windows (that is, providing Windows/Unix interoperablity? No, that's not a key goal. From the Cygwin main web page: Cygwin is a Linux-like environment for Windows Well, I (and my employer) would not be using Cygwin if it wasn't for the Windows integration, in particular the ability to plug POSIX and Windows programs together. If I just wanted to run Linux software on Windows, I'd use a virtual machine or coLinux. While Cygwin's lower resource usage is nice to have, that's easily outweighed by the inevitable compatibility and performance drawbacks that come with building on top of Win32. There are allot of different reasons people choose to use Cygwin. Correct. And, people apparently find Cygwin useful even when their usage does not 100% align with the stated project goals. That does not mean that we're going to change the goals and, given the project goals, it certainly doesn't mean that it's a bug when a Windows-specific usage like a MS-DOS path doesn't work in a Cygwin program. cgf -- 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: Windows-style pathname does not work as command - why?
Date: Wed, 8 Sep 2010 15:39:09 -0400 From: cgf To: cygwin Subject: Re: Windows-style pathname does not work as command - why? Isn't the whole reason for Cygwin actually to enable doing Unixy things in Windows (that is, providing Windows/Unix interoperablity? No, that's not a key goal. From the Cygwin main web page: Cygwin is a Linux-like environment for Windows Well, I (and my employer) would not be using Cygwin if it wasn't for the Windows integration, in particular the ability to plug POSIX and Windows programs together. If I just wanted to run Linux software on Windows, I'd use a virtual machine or coLinux. While Cygwin's lower resource usage is nice to have, that's easily outweighed by the inevitable compatibility and performance drawbacks that come with building on top of Win32. There are allot of different reasons people choose to use Cygwin. Correct. And, people apparently find Cygwin useful even when their usage does not 100% align with the stated project goals. That does not mean that we're going to change the goals and, given the project goals, it certainly doesn't mean that it's a bug when a Windows-specific usage like a MS-DOS path doesn't work in a Cygwin program. To be fair (as opposed to just mean) Cygwin does provide other tools to aid in interoperability, such as, cygpath and run (and run2). Being Unixy (Linuxy) is just more important than supporting Windowsisms. If the priorities were reversed, Cygwin would be less useful overall. Thanks, ...Karl -- 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: Windows-style pathname does not work as command - why?
On 9/8/2010 5:19 PM, Karl M wrote: snip To be fair (as opposed to just mean) Cygwin does provide other tools to... Fair? And not mean?? Who let this guy in? Karl, you obviously just don't fit in here. ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Windows-style pathname does not work as command - why?
I don't quite understand this behavior: $ ls C:\\tools\\emacs-23.2\\bin\\runemacs.exe C:\tools\emacs-23.2\bin\runemacs.exe $ C:\\tools\\emacs-23.2\\bin\\runemacs.exe bash: C:\tools\emacs-23.2\bin\runemacs.exe: command not found In particular, why is it that bash does not understand that Windows pathname when it is used as a command argument, even though bash and Cygwin clearly understand it when it is used as a command argument? Is that behavior a bug (e.g., does bash try to judge whether the command is an absolute vs. relative pathname without either first converting to a Unix-style pathname or otherwise recognizing Windows-style pathname)? Or is it some known irregularity (resulting from trying to handle both Windows- and Unix-style pathnames) that couldn't be resolved? Thanks, Daniel -- 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: Windows-style pathname does not work as command - why?
On 09/02/2010 11:45 AM, Daniel Barclay wrote: I don't quite understand this behavior: $ ls C:\\tools\\emacs-23.2\\bin\\runemacs.exe C:\tools\emacs-23.2\bin\runemacs.exe $ C:\\tools\\emacs-23.2\\bin\\runemacs.exe bash: C:\tools\emacs-23.2\bin\runemacs.exe: command not found In particular, why is it that bash does not understand that Windows pathname when it is used as a command argument, even though bash and Cygwin clearly understand it when it is used as a command argument? Is that behavior a bug (e.g., does bash try to judge whether the command is an absolute vs. relative pathname without either first converting to a Unix-style pathname or otherwise recognizing Windows-style pathname)? You're not the first to notice this, but it's also not the highest priority on my list to look into, because we already recommend using POSIX style paths in the first place. Or is it some known irregularity (resulting from trying to handle both Windows- and Unix-style pathnames) that couldn't be resolved? Oh, I'm sure that bash could be patched to be smarter about DOS-style pathnames. But no one has been bothered by it enough to write a patch yet. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- 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: Windows-style pathname does not work as command - why?
I suggest for your convenience, you try making a symbolic link ... Perhaps something like ... $ ln -s /cygdrive/c/tools/emacs-23.2/bin/runemacs.exe /usr/local/bin/runemacs Then open up a fresh shell and see if 'runemacs' now works for you. (the shell you made the symbolic link in, will likely NOT be able to use the new link) new-shell$ runemacs When I tried something similar to your situation, but with VIM I got the following -- $ C:\\PROGRA~1\\vim\\vim72\\gvim.exe cygwin warning: MS-DOS style path detected: /usr/local/bin/C:\PROGRA~1\vim\vim72\gvim.exe Preferred POSIX equivalent is: /usr/local/bin/C:/PROGRA~1/vim/vim72/gvim.exe CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames bash: C:\PROGRA~1\vim\vim72\gvim.exe: command not found - While it may not be easy to make bash properly handle dos style paths for executeables, I do believe that you can make your life much easier with well chosen symbolic links. -- 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: Windows-style pathname does not work as command - why?
On Thu, Sep 02, 2010 at 12:13:12PM -0600, Eric Blake wrote: On 09/02/2010 11:45 AM, Daniel Barclay wrote: I don't quite understand this behavior: $ ls C:\\tools\\emacs-23.2\\bin\\runemacs.exe C:\tools\emacs-23.2\bin\runemacs.exe $ C:\\tools\\emacs-23.2\\bin\\runemacs.exe bash: C:\tools\emacs-23.2\bin\runemacs.exe: command not found In particular, why is it that bash does not understand that Windows pathname when it is used as a command argument, even though bash and Cygwin clearly understand it when it is used as a command argument? Is that behavior a bug (e.g., does bash try to judge whether the command is an absolute vs. relative pathname without either first converting to a Unix-style pathname or otherwise recognizing Windows-style pathname)? You're not the first to notice this, but it's also not the highest priority on my list to look into, because we already recommend using POSIX style paths in the first place. Or is it some known irregularity (resulting from trying to handle both Windows- and Unix-style pathnames) that couldn't be resolved? Oh, I'm sure that bash could be patched to be smarter about DOS-style pathnames. But no one has been bothered by it enough to write a patch yet. And, trying hard to make MS-DOS stuff work is sorta counter to the whole reason for Cygwin. cgf -- 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
