filesystem: remove /usr/bin/cmd

[lazka]

It's not clear why it is there (except for changing COMSPEC somehow, but why?), and it's causing problems such as python/cpython#127001

Ideas what this could break welcome.

[lazka]

@Alexpux do you happen to know why we have /usr/bin/cmd?

[smalltalkman]

I estimate that deleting cmd will cause many software builds to fail, you can refer to: rmyorston/busybox-w32#297 (comment)

[lazka]

I estimate that deleting cmd will cause many software builds to fail, you can refer to: rmyorston/busybox-w32#297 (comment)

What would removing /usr/bin/cmd change there? Wouldn't cmd.exe not behave the same?

[smalltalkman]

I estimate that deleting cmd will cause many software builds to fail, you can refer to: rmyorston/busybox-w32#297 (comment)

What would removing /usr/bin/cmd change there? Wouldn't cmd.exe not behave the same?

Removing /usr/bin/cmd will cause cmd //c echo "$1" to enter the cmd console and hang.

The main purpose of func_convert_core_msys_to_w32 is to use cmd in cygwin (msys) to convert unix paths to w32 paths. For example, in my msys2 (under win7, not necessarily the latest):

lenovo@lenovo-PC MSYS /c/Users/lenovo/Desktop
# cmd //c echo /
D:/gym/softwares/msys64/

# cmd //c echo /abc/def
D:/gym/softwares/msys64/abc/def

# cmd //c echo /d/abc/def
D:/abc/def

# cmd //c echo d:\\abd
d:\abd

# cmd //c echo d:\abd
d:abd

# cmd //c echo d:/
d:/

These tasks cannot be accomplished by cmd.exe in Windows.

The above should only apply to cygwin (msys), not to busybox-w32. However, I had to use a script like the following to bypass this limitation in busybox-w32.

#!/bin/sh

if [ x"\$1" == x"//c" ]; then
  shift
  "\$COMSPEC" "/c" "\$@"
else
  "\$COMSPEC" "\$@"
fi

Additionally, the libtool commits related to cmd //c echo ... exist at autotools-mirror/libtool@d9033b1 and autotools-mirror/libtool@ac40b5f . These commits should explain the cause better.

[lazka]

Removing /usr/bin/cmd will cause cmd //c echo "$1" to enter the cmd console and hang.

Works fine here, what am I missing?

$ /C/WINDOWS/system32/cmd.exe //c echo "ok"
ok

[smalltalkman]

Removing /usr/bin/cmd will cause cmd //c echo "$1" to enter the cmd console and hang.

Works fine here, what am I missing?

$ /C/WINDOWS/system32/cmd.exe //c echo "ok"
ok

About one year ago, I encountered a similar problem. I remember that the test results at that time showed that cmd //c echo ... would hang, and I had to manually kill the cmd process to recover. I just retested it and the results showed that it did work. So please ignore the bad conclusion.

However, deleting /usr/bin/cmd will affect access to cmd when MSYS2_PATH_TYPE=strict is used, which makes PATH very small (I used to use this setting a lot, but rarely do now).

[lazka]

However, deleting /usr/bin/cmd will affect access to cmd when MSYS2_PATH_TYPE=strict is used, which makes PATH very small (I used to use this setting a lot, but rarely do now).

Good point. Hopefully not that common though in combination.

The Python issue motivating this PR has been fixed upstream, so I'm going to leave this open for a while longer as it's not that urgent.

[1480c1]

I think even in strict, we should not provide /usr/bin/cmd as that should be something the user opts into having by adding C:\Windows\system32\ to their PATH or by calling $COMSPEC directly. As a bad equivalent, we don't provide /usr/bin/powershell nor any other wrapper for programs within C:\Windows\system32\ as just a file, so it's odd that we provide /usr/bin/cmd as a wrapper.

A situation where I find /usr/bin/cmd downright annoying is if I have C:\msys64\usr\bin in my PATH and I call cmd to check something in command prompt or to test a batch script, powershell will error out as it tries to call C:\msys64\usr\bin\cmd. For me, the purpose of having that in my PATH is so I can call bash -l, grep, etc. directly from powershell without needing to open up mintty or a new profle in Windows Terminal every time.