Subject: Re: cygpath
From: [email-masked] (Laurent Charles)

13 Nov 1998 16:30:11 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [email-masked]

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

[email-masked] 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
"[email-masked]" with one line of text: "help".