[Mingw-users] MSYS Path to Windows Path

[Brendon Costa]

Hi All,

I was wondering if there is an existing way to convert a MSYS
path/filename into a windows path/filename?

MSYS will usually convert automatically for me, but I have a few
arguments like -I/c/dev/BJC/include that will not because they are
prefixed with the -I (Note am using MSVC not gcc for this one). This
is being done in a script so I have the luxury of scripting a
conversion function.

Note: I have to be able to convert both directory names and file
names. I was looking at a few methods.

1) Convert /c/ to c:/

Problems:
* Does not work with relative paths that may exist in the MSYS fstab
file. E.g. I have /usr/local mapped to C:\msys_local if the relative
path resulted into this place, then the above method would fail.
* Need to add for every drive not just /c/ as i have a lot of
development code on a network drive /x/ etc.

2) Remove the filename from the end of the identifier if one exists
and then do a cd into the directory and then pwd -W to get the name.

Problems:
* This will not always work because sometimes the file/directory
structure does not yet exist and will be created by the command so the
cd fails.

3) Break the string into a space separated list by substituting all
'/' characters with space characters and iterating over the list in a
for loop. For each item I attempt to cd into it. If the cd fails then
the directory does not exist. Get the pwd -W of the directory before
the one that failed, and then add the rest of the items to then then
of the pwd -W result separated by '/' characters.

Problems:
* A bit complicated. Also will not keep relative paths that can be
kept. I.e. if I am in /c/dev/BJC/blah and need to convert
"../../thing" from a MSYS path to a windows path, then the the
resulting windows path would be "C:/dev/thing", but it could be
"../../thing"


Number 3 seems like a reasonable option to me, but before I implement
it I thought I would ask if there is a standard way of achieving this
that already exists or any recommendations people would have?

By the way I had a quick look in the FAQ section of the Wiki and did
not find any items for this. Maybe it would be worth adding this as a
FAQ (Though not sure how "Frequent" this question would be)?

Thanks,
Brendon.

[Jeremy Bettis]

Post by Brendon Costa
I was wondering if there is an existing way to convert a MSYS
path/filename into a windows path/filename?

Since MSYS will rewrite the filenames when it passes them to non-msys
programs, you can create a tiny little program that is not an msys program
and pass the filenames to it.

i.e.
/* msys2dos.c */
#include <stdio.h>

int main(int argc, char**argv) {
int i;
for(i=1;i<argc;i++) {
printf("%s\n", argv[i]);
}
return 0;
}

[Keith Marshall]

Post by Jeremy Bettis

 I was wondering if there is an existing way to convert a MSYS
 path/filename into a windows path/filename?

Since MSYS will rewrite the filenames when it passes them to non-msys
programs, you can create a tiny little program that is not an msys
program and pass the filenames to it.

There's no need to even go to that length.

[Earnie Boyd]

Post by Jeremy Bettis

Post by Brendon Costa
I was wondering if there is an existing way to convert a MSYS
path/filename into a windows path/filename?

Since MSYS will rewrite the filenames when it passes them to non-msys
programs, you can create a tiny little program that is not an msys program
and pass the filenames to it.
i.e.
/* msys2dos.c */
#include <stdio.h>
int main(int argc, char**argv) {
int i;
for(i=1;i<argc;i++) {
printf("%s\n", argv[i]);
}
return 0;
}

You don't have to get that fancy. All you need is:

cmd //c echo /foo


Earnie Boyd

http://shop.siebunlimited.com

[Keith Marshall]

Post by Earnie Boyd

 I was wondering if there is an existing way to convert a MSYS
 path/filename into a windows path/filename?

 Since MSYS will rewrite the filenames when it passes them to non-msys
 programs, you can create a tiny little program that is not an msys
program and pass the filenames to it.
[program code snipped]...

cmd //c echo /foo

Nice trick, Earnie. I'll be sure to include it in the MinGWiki HOWTO I
plan to write.

Post by Earnie Boyd

By the way I had a quick look in the FAQ section of the Wiki and did
not find any items for this. Maybe it would be worth adding this as a
FAQ (Though not sure how "Frequent" this question would be)?

... As for frequency, you would be the first in a few years (maybe I
exagerate a bit) to ask; it certainly isn't frequent.

Hmm. I can recall three or four separate instances, within the past
eighteen months or so, that I've answered this very question. The most
memorable was at the time when I wrote the MSYS_AC_CANONICAL_PATH macro,
for use in the autoconfiscated man package. In that situation, I don't
think the `cmd //c echo /foo' trick would have been suitable, but that
doesn't make it any less useful, nevertheless.

I do think some sort of MinGWiki write up is justified; I'll attend to
it, when I can find the time.

Regards,
Keith.

[Earnie Boyd]

Post by Keith Marshall

Post by Earnie Boyd

Post by Jeremy Bettis

Post by Brendon Costa
I was wondering if there is an existing way to convert a MSYS
path/filename into a windows path/filename?

Since MSYS will rewrite the filenames when it passes them to non-msys
programs, you can create a tiny little program that is not an msys
program and pass the filenames to it.
[program code snipped]...

cmd //c echo /foo

Nice trick, Earnie. I'll be sure to include it in the MinGWiki HOWTO I
plan to write.

Post by Earnie Boyd

Post by Jeremy Bettis
By the way I had a quick look in the FAQ section of the Wiki and did
not find any items for this. Maybe it would be worth adding this as a
FAQ (Though not sure how "Frequent" this question would be)?

... As for frequency, you would be the first in a few years (maybe I
exagerate a bit) to ask; it certainly isn't frequent.

Hmm. I can recall three or four separate instances, within the past
eighteen months or so, that I've answered this very question. The most
memorable was at the time when I wrote the MSYS_AC_CANONICAL_PATH macro,
for use in the autoconfiscated man package. In that situation, I don't
think the `cmd //c echo /foo' trick would have been suitable, but that
doesn't make it any less useful, nevertheless.

I couldn't really remember and there was a point in time when I just
deleted the list mail without reading it. That is why I said that I
was probably exagerating.

Post by Keith Marshall
I do think some sort of MinGWiki write up is justified; I'll attend to
it, when I can find the time.

Time, now there's a commodity worth investing in. ;) Too bad I can't
trade for more of it. LOL.

Earnie Boyd

http://shop.siebunlimited.com

[Earnie Boyd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All,
I was wondering if there is an existing way to convert a MSYS
path/filename into a windows path/filename?
MSYS will usually convert automatically for me, but I have a few
arguments like -I/c/dev/BJC/include that will not because they are
prefixed with the -I (Note am using MSVC not gcc for this one). This
is being done in a script so I have the luxury of scripting a
conversion function.

This is fixed in the 1.0.11 snapshot. If you use -I /c/dev/BJC/include
it will convert it properly.

Note: I have to be able to convert both directory names and file
names. I was looking at a few methods.
1) Convert /c/ to c:/
* Does not work with relative paths that may exist in the MSYS fstab
file. E.g. I have /usr/local mapped to C:\msys_local if the relative
path resulted into this place, then the above method would fail.
* Need to add for every drive not just /c/ as i have a lot of
development code on a network drive /x/ etc.
2) Remove the filename from the end of the identifier if one exists
and then do a cd into the directory and then pwd -W to get the name.
* This will not always work because sometimes the file/directory
structure does not yet exist and will be created by the command so the
cd fails.
3) Break the string into a space separated list by substituting all
'/' characters with space characters and iterating over the list in a
for loop. For each item I attempt to cd into it. If the cd fails then
the directory does not exist. Get the pwd -W of the directory before
the one that failed, and then add the rest of the items to then then
of the pwd -W result separated by '/' characters.
* A bit complicated. Also will not keep relative paths that can be
kept. I.e. if I am in /c/dev/BJC/blah and need to convert
"../../thing" from a MSYS path to a windows path, then the the
resulting windows path would be "C:/dev/thing", but it could be
"../../thing"
Number 3 seems like a reasonable option to me, but before I implement
it I thought I would ask if there is a standard way of achieving this
that already exists or any recommendations people would have?
By the way I had a quick look in the FAQ section of the Wiki and did
not find any items for this. Maybe it would be worth adding this as a
FAQ (Though not sure how "Frequent" this question would be)?

Really now, all of this stuff should work already in MSYS. If you find
something with the current DLL that doesn't work I need to know. I
don't supply a tool such as cygpath because it shouldn't be needed. As
for frequency, you would be the first in a few years (maybe I exagerate
a bit) to ask; it certainly isn't frequent.

Earnie Boyd

http://shop.siebunlimited.com

[Earnie Boyd]

Post by Earnie Boyd
Really now, all of this stuff should work already in MSYS. If you find
something with the current DLL that doesn't work I need to know. I

By current DLL I mean the one in the Snapshot package.


Earnie Boyd

http://shop.siebunlimited.com

[Brendon Costa]

Post by Earnie Boyd

Post by Brendon Costa
MSYS will usually convert automatically for me, but I have a few
arguments like -I/c/dev/BJC/include that will not because they are
prefixed with the -I (Note am using MSVC not gcc for this one). This
is being done in a script so I have the luxury of scripting a
conversion function.

This is fixed in the 1.0.11 snapshot. If you use -I /c/dev/BJC/include
it will convert it properly.

I am downloading it now, however remember that in my situation there is
no space between the -I and the /c/dev/BJC/include. It also is not
restricted to -I, but can be any number of variations like
- -FI/c/dev/BJC/blah.h or -Tp/c/dev/BJC/src/blah.cpp or
- -Fe/c/dev/build/blah.exe ...

Make note that there are no spaces between the options and the files, so
as far as i can tell it would be very difficult for MSYS to determine
what is part of a valid filename and what is part of the option. In fact
i would not expect MSYS to convert these for me at all, which is what is
happening.

Before i install it, does this snapshot fix the problem for those cases
i just mentioned above as well as -I /c/dev/BJC/include?

Post by Earnie Boyd
Really now, all of this stuff should work already in MSYS. If you find
something with the current DLL that doesn't work I need to know. I
don't supply a tool such as cygpath because it shouldn't be needed. As
for frequency, you would be the first in a few years (maybe I exagerate
a bit) to ask; it certainly isn't frequent.

I don't consider the functionality i am seeing from msys as a bug,
rather i am using it a little differently than it expects to be used so
I want to convert the paths myself and then use them. I will try the cmd
//c echo /foo

Thanks for the reply.
Brendon Costa.

[Earnie Boyd]

Post by Brendon Costa
I am downloading it now, however remember that in my situation there is
no space between the -I and the /c/dev/BJC/include. It also is not
restricted to -I, but can be any number of variations like
- -FI/c/dev/BJC/blah.h or -Tp/c/dev/BJC/src/blah.cpp or
- -Fe/c/dev/build/blah.exe ...
Make note that there are no spaces between the options and the files, so
as far as i can tell it would be very difficult for MSYS to determine
what is part of a valid filename and what is part of the option. In fact
i would not expect MSYS to convert these for me at all, which is what is
happening.
Before i install it, does this snapshot fix the problem for those cases
i just mentioned above as well as -I /c/dev/BJC/include?

No, the limitation is to - followed by character followed by /. So
-I/my/include/path works but -FI/c/dev/BJC/blah.h doesn't, yet. What
do the users think, should I allow any number of characters between -
and /?

Earnie Boyd

http://shop.siebunlimited.com

[Georg Ritter]

Post by Earnie Boyd

Post by Brendon Costa
I am downloading it now, however remember that in my situation there is
no space between the -I and the /c/dev/BJC/include. It also is not
restricted to -I, but can be any number of variations like
- -FI/c/dev/BJC/blah.h or -Tp/c/dev/BJC/src/blah.cpp or
- -Fe/c/dev/build/blah.exe ...
Make note that there are no spaces between the options and the files, so
as far as i can tell it would be very difficult for MSYS to determine
what is part of a valid filename and what is part of the option. In fact
i would not expect MSYS to convert these for me at all, which is what is
happening.
Before i install it, does this snapshot fix the problem for those cases
i just mentioned above as well as -I /c/dev/BJC/include?

No, the limitation is to - followed by character followed by /. So
-I/my/include/path works but -FI/c/dev/BJC/blah.h doesn't, yet. What
do the users think, should I allow any number of characters between -
and /?

Dear Earnie,

I vote for yess ;-)

-Wl,--out-implib,/d/temp/xxxx/lib/arch-mingw-Debug/libcore.dll.a

Greets,

Georg

Post by Earnie Boyd
Earnie Boyd
http://shop.siebunlimited.com
_______________________________________________
MinGW-users mailing list
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Ralf Wildenhues]

Post by Georg Ritter
-Wl,--out-implib,/d/temp/xxxx/lib/arch-mingw-Debug/libcore.dll.a

-Xlinker --out-implib -Xlinker /d/temp/xxxx/lib/arch-mingw-Debug/libcore.dll.a

Cheers,
Ralf

[Earnie Boyd]

Post by Georg Ritter

Post by Earnie Boyd

Post by Brendon Costa
I am downloading it now, however remember that in my situation there is
no space between the -I and the /c/dev/BJC/include. It also is not
restricted to -I, but can be any number of variations like
- -FI/c/dev/BJC/blah.h or -Tp/c/dev/BJC/src/blah.cpp or
- -Fe/c/dev/build/blah.exe ...
Make note that there are no spaces between the options and the files, so
as far as i can tell it would be very difficult for MSYS to determine
what is part of a valid filename and what is part of the option. In fact
i would not expect MSYS to convert these for me at all, which is what is
happening.
Before i install it, does this snapshot fix the problem for those cases
i just mentioned above as well as -I /c/dev/BJC/include?

No, the limitation is to - followed by character followed by /. So
-I/my/include/path works but -FI/c/dev/BJC/blah.h doesn't, yet. What
do the users think, should I allow any number of characters between -
and /?

Dear Earnie,
I vote for yess ;-)
-Wl,--out-implib,/d/temp/xxxx/lib/arch-mingw-Debug/libcore.dll.a

This one is already fixed in the Snapshot.


Earnie Boyd

http://shop.siebunlimited.com

[Greg Chicares]

Post by Earnie Boyd

Post by Brendon Costa
Before i install it, does this snapshot fix the problem for those cases
i just mentioned above as well as -I /c/dev/BJC/include?

No, the limitation is to - followed by character followed by /. So
-I/my/include/path works but -FI/c/dev/BJC/blah.h doesn't, yet. What
do the users think, should I allow any number of characters between -
and /?

Since you asked, I would like
some_command | sed -e ';/Error/!d'
to work without the ';' I added to make a native sed work with MSYS.

~[0]$echo "Error" | /usr/bin/sed -e '/Error/!d'
Error
~[0]$echo "Error" | /c/usr/bin/sed -e '/Error/!d'
c:\usr\bin\sed.exe: -e expression #1, char 1: Unknown command: `C'
~[1]$echo "Error" | /c/usr/bin/sed -e ';/Error/!d'
Error

I know we've discussed that before, but I'm concerned that extending
this logic to accommodate '-FI/c/dev/BJC/blah.h' might break some
other usage and require more workarounds like the ';' above.

[Brendon Costa]

Post by Earnie Boyd

Post by Brendon Costa
Before i install it, does this snapshot fix the problem for those cases
i just mentioned above as well as -I /c/dev/BJC/include?

No, the limitation is to - followed by character followed by /. So
-I/my/include/path works but -FI/c/dev/BJC/blah.h doesn't, yet. What
do the users think, should I allow any number of characters between -
and /?

I would not even expect -I/c/dev to translate the filename for me. As
Greg mentioned, this changes operation of other programs. sed was a
great example. I don't think it is necessary to have this additional
functionality for -FI/c/blah.

Brendon.

[Keith Marshall]

On Thursday 15 June 2006 10:42 pm, Earnie Boyd wrote:
[In respect of the automatic path translation performed in MSYS]

What do the users think, should I allow any number of characters
between - and /?

The whole issue is, unfortunately, a heuristic nightmare. To borrow a
quote from Bruno Haible, "any algorithm, which relies on heuristics, is
broken by design".

It's unfortunate that any such translation is required at all, but of
course MSYS wouldn't be very effective without it. The problem is, where
do you stop with the heuristics? There are already situations where the
existing algorithm goes too far; Greg's sed example is a typical case in
point; there is also a problem with the emacs build procedure, which has
been discussed in the past, where unwanted translation occurs.

I've previously suggested that any string enclosed in quotes should be
exempt from translation, but do the quotes remain in place to be seen by
the translation routine? Earnie has suggested that bash has already
removed them, by the time they get to this routine, and I've no reason to
doubt that this is so.

However aggressively this heuristic algorithm tries to identify arguments
which should be translated, there are always going to be edge cases where
it gets it wrong. What we have at the moment isn't perfect; since it's
heuristic, it never can be, but it's a reasonable compromise for a
majority of situations. I vote we leave it alone, unless an algorithm
can be suggested, which gives the user a *portable*, and deterministic,
way to express arguments, such that the translation routine *knows* when
it is required to leave them alone.

Regards,
Keith.

[Ralf Wildenhues]

Hello Keith,

Post by Keith Marshall
What we have at the moment isn't perfect; since it's
heuristic, it never can be, but it's a reasonable compromise for a
majority of situations. I vote we leave it alone, unless an algorithm
can be suggested, which gives the user a *portable*, and deterministic,
way to express arguments, such that the translation routine *knows* when
it is required to leave them alone.

I second this. At least then it doesn't turn out to be a moving target.
It's much easier to adjust to a known heuristic (and no, don't tell me
the heuristic is broken if autotools need to adjust: there will always
be a bug report asking them to do so, some way or another). Which
brings up my question: is there some concise documentation (other than
the source code) which documents the rules?

Cheers,
Ralf

[Tuomo Latto]

Post by Ralf Wildenhues

Post by Keith Marshall
What we have at the moment isn't perfect; since it's
heuristic, it never can be, but it's a reasonable compromise for a
majority of situations. I vote we leave it alone, unless an algorithm
can be suggested, which gives the user a *portable*, and deterministic,
way to express arguments, such that the translation routine *knows* when
it is required to leave them alone.

I second this. At least then it doesn't turn out to be a moving target.
It's much easier to adjust to a known heuristic (and no, don't tell me
the heuristic is broken if autotools need to adjust: there will always
be a bug report asking them to do so, some way or another). Which
brings up my question: is there some concise documentation (other than
the source code) which documents the rules?

The heuristic is probably ok as it is.
Although, some documentation on it would be nice.


I think a lot of these unix/win path problems could be resolved
if there were some prefixes you could use to explicitly force
the path translation. These prefixes would then be removed during
translation.

For example, you could use, say, some double pound-sign prefixes.
Why pound sign? Well, I for one have *never* seen a command line
containing a pound sign..
If the prefix was in the form of '££B£', where B was a modifier list, eg:
-'=' would instruct that only the stuff after the first '='
or ':' is translated.
-':' would treat the parameter as unix style path list and convert
it to windows style.

And so on.
What do you think?

[Luke Dunstan]

Subject: Re: [Mingw-users] MSYS Path to Windows Path
Date: Sat, 17 Jun 2006 16:57:03 +0300

Post by Ralf Wildenhues

Post by Keith Marshall
What we have at the moment isn't perfect; since it's
heuristic, it never can be, but it's a reasonable compromise for a
majority of situations. I vote we leave it alone, unless an algorithm
can be suggested, which gives the user a *portable*, and deterministic,
way to express arguments, such that the translation routine *knows* when
it is required to leave them alone.

I second this. At least then it doesn't turn out to be a moving target.
It's much easier to adjust to a known heuristic (and no, don't tell me
the heuristic is broken if autotools need to adjust: there will always
be a bug report asking them to do so, some way or another). Which
brings up my question: is there some concise documentation (other than
the source code) which documents the rules?

The heuristic is probably ok as it is.
Although, some documentation on it would be nice.
I think a lot of these unix/win path problems could be resolved
if there were some prefixes you could use to explicitly force
the path translation. These prefixes would then be removed during
translation.
For example, you could use, say, some double pound-sign prefixes.
Why pound sign? Well, I for one have *never* seen a command line
containing a pound sign..

That's because the "pound sign" character is not in the ASCII character set
and is not on US keyboards (unless you call # a pound sign, but then that's
a comment character in Bourne shell). I know you were just using it as an
example though.

Luke

-'=' would instruct that only the stuff after the first '='
or ':' is translated.
-':' would treat the parameter as unix style path list and convert
it to windows style.
And so on.
What do you think?
--
Tuomo
... Don't read everything you believe

[Keith MARSHALL]

Post by Tuomo Latto
The heuristic is probably ok as it is.
Although, some documentation on it would be nice.

Yep; if some kind soul, with time on their hands, felt inclined
to write some... :-)

Post by Tuomo Latto
I think a lot of these unix/win path problems could be resolved
if there were some prefixes you could use to explicitly force
the path translation. These prefixes would then be removed
during translation.
For example, you could use, say, some double pound-sign prefixes.

But that would violate the requirement for portability; how, for
example, would such a sequence be handled in a Makefile, indended
for use across the platform boundary between MSYS and *nix?

OTOH, if you are talking of extended functionality, explicitly
restricted to MSYS only, then that is violating the MSYS minimilist
design objective. While it might be nice to have, is the effort of
implementation really justified?

Regards,
Keith.