From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Charles To: gnu-win32@cygnus.com Subject: Re: cygpath Date: Fri, 13 Nov 1998 02:57:00 -0000 Message-id: <364C09B5.8F6FBA57@st.com> References: <36484B31.A6089DF@st.com> X-SW-Source: 1998-11/msg00589.html 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".