How to prevent MSYS to convert the file path for an external program
Asked Answered
F

3

15

I'm porting a Linux script to Windows & MinGW, which accesses the Android phone through ADB.

Sometime I need to pass the Android's file path as ADB command line option.

However, when invoking the ADB.exe, MinGW translates it to Windows' path.

For example,

adb shell cat /proc/version

Is translated as follows, resulting "No such file or directory" error in Android.

adb shell cat C:/Program Files (x86)/Git/proc/version

I found double-quotation helps to prevent that.

adb shell "cat /proc/version"

But is there any global siwtches or env variables to prevent MinGW for this converstion ?

The MinGW I'm using came with the "Git for Windows" package.

EDITED : I also hit another scnario, I cannot work-around with the double quotation.

$ adb push test1.mp3 /data
failed to copy 'test1.mp3' to 'C:/Program Files (x86)/Git/data': No such file or directory

$ adb push test1.mp3 "/data"
failed to copy 'test1.mp3' to 'C:/Program Files (x86)/Git/data': No such file or directory
Flavorous answered 16/2, 2015 at 2:23 Comment(0)
F
14

Just found starting the double-slash is the charm.

https://web.archive.org/web/20201112005258/http://www.mingw.org/wiki/Posix_path_conversion

An argument starting with 2 or more / is considered an escaped Windows style switch and will be passed with the leading / removed and all \ changed to /.

Except that if there is a / following the leading block of /, the argument is considered to be a UNC path and the leading / is not removed.

| Argument from MSYS program | Sent to native Windows program as | Sent to native Windows program as
| //foobar                   | /foobar                           | double /  prevents conversion
| //foo\bar                  | /foo/bar                          | \  converted to /
| //foo/bar                  | //foo/bar                         | interpreted as UNC path, leading /  not removed
Flavorous answered 16/2, 2015 at 7:38 Comment(0)
G
17

But is there any global switches or env variables to prevent MinGW for this conversion ?

Yes. Use this environment variable:

MSYS_NO_PATHCONV=1

e.g.

MSYS_NO_PATHCONV=1 adb shell cat /proc/version

Beware: programs might not work properly they expect Windows paths.

To work around this you can use escaping as mentioned on the documentation page (look at the bottom):

adb shell cat //proc\version

Rule: first / of parameter is duplicated, rest / are replaced with \

Depending on escaping (e.g. in .sh scripts) used you might need to duplicate \ character:

adb shell cat //proc\\version

This way only parameters you wrote with extra / prefix will be passed without conversion to Windows paths.

Goran answered 19/1, 2018 at 19:50 Comment(0)
F
14

Just found starting the double-slash is the charm.

https://web.archive.org/web/20201112005258/http://www.mingw.org/wiki/Posix_path_conversion

An argument starting with 2 or more / is considered an escaped Windows style switch and will be passed with the leading / removed and all \ changed to /.

Except that if there is a / following the leading block of /, the argument is considered to be a UNC path and the leading / is not removed.

| Argument from MSYS program | Sent to native Windows program as | Sent to native Windows program as
| //foobar                   | /foobar                           | double /  prevents conversion
| //foo\bar                  | /foo/bar                          | \  converted to /
| //foo/bar                  | //foo/bar                         | interpreted as UNC path, leading /  not removed
Flavorous answered 16/2, 2015 at 7:38 Comment(0)
W
1

Please, can we get the terminology right here? MinGW does no path translation, such as you describe; it is the MSYS build environment, provided by MinGW.org as a companion to MinGW, which does this, so I guess you are actually using the version of MSYS supplied with Git for Windows.

I'm pleased that you have found the magic bullet which works in your case, but please be aware that there are some corner cases in which this "double slash" trick doesn't suffice; if you run into one of these, you may wish to consider Cygwin as an alternative hosting shell on Windows.

Wastebasket answered 10/3, 2015 at 8:40 Comment(3)
In fact, MinGW is a native Windows build of GCC, accompanied by further native builds of tools which are complementary to the GCC tool chain. All tools in the MinGW collection work with native Windows paths; they have no need to perform path translations such as you describe.Wastebasket
MSYS is a forked subset of an early version of Cygwin, which has been modified to co-operate better (in general) with the MinGW tools than Cygwin does; it is particularly suited to managing project builds using MinGW, under the direction of makefiles intended for use on POSIX systems. It is when any MSYS tool hands off execution to a MinGW tool, (or to any other native Windows application), that MSYS performs the path translation. (AIUI, Cygwin can do similar translation, but less transparently).Wastebasket
Thank you for the clarification. I just changed the title.Flavorous

© 2022 - 2024 — McMap. All rights reserved.