Git Bash - string parameter with '/' at start is being expanded to a file path. How to stop this?

Earlier today, I was trying to generate a certificate with a DNSName entry in the SubjectAltName extension:

$ openssl req -new -subj "/C=GB/CN=foo" -addext "subjectAltName = DNS:foo.co.uk" \
-addext "certificatePolicies = 1.2.3.4" -key ./private-key.pem -out ~/req.pem

This command led to the following error message:

name is expected to be in the format /type0=value0/type1=value1/type2=... where characters may be escaped by . This name is not in that format: 'C:/Program Files/Git/C=GB/CN=foo' problems making Certificate Request

How can I stop Git Bash from treating this string parameter as a filepath, or at least stop it from making this alteration?

The release notes to the Git Bash 2.21.0 update today mentioned this as a known issue. Fortunately, they also described two solutions to the problem:

If you specify command-line options starting with a slash, POSIX-to-Windows path conversion will kick in converting e.g. "/usr/bin/bash.exe" to "C:\Program Files\Git\usr\bin\bash.exe". When that is not desired -- e.g. "--upload-pack=/opt/git/bin/git-upload-pack" or "-L/regex/" -- you need to set the environment variable MSYS_NO_PATHCONV temporarily, like so:

MSYS_NO_PATHCONV=1 git blame -L/pathconv/ msys2_path_conv.cc

Alternatively, you can double the first slash to avoid POSIX-to-Windows path conversion, e.g. "//usr/bin/bash.exe".

However, MSYS_NO_PATHCONV=1 can cause problems if you're using a tilde ('~') to reprent your home folder:

$ MSYS_NO_PATHCONV=1 openssl req -new -subj "/C=GB/CN=foo" -addext "subjectAltName = DNS:foo.co.uk" -addext "certificatePolicies = 1.2.3.4" -key ./userkeys/user_device_priv.pem -out ~/req.pem

Can't open /c/Users/AJM/req.pem for writing, No such file or directory
24780:error:02001003:system library:fopen:No such process:../openssl-1.1.1u/crypto/bio/bss_file.c:69:fopen('/c/Users/AJM/req.pem','w')
24780:error:2006D080:BIO routines:BIO_new_file:no such file:../openssl-1.1.1u/crypto/bio/bss_file.c:76:

In discussion with @quetzalcoatl in comments on my original question, MSYS2_ARG_CONV_EXCL="*" was suggested as an alternative to MSYS_NO_PATHCONV=1. I have tested this, and can confirm that it works just as well, but unfortunately also has the same problem with the ~ character.

Using information from

• https://www.msys2.org/wiki/Porting/
• https://www.msys2.org/docs/filesystem-paths/#automatic-unix-windows-path-conversion

we can achieve a more fine-grained control, and eliminate the problem with ~. However, this comes at the cost of having to manually identify all of the various "arguments that look like Unix paths while they are not":

$ MSYS2_ARG_CONV_EXCL='/C' openssl req -new -subj "/C=GB/CN=foo" -addext "subjectAltName = DNS:foo.co.uk" -addext "certificatePolicies = 1.2.3.4" -key ./userkeys/user_device_priv.pem -out ~/req.pem

# Works OK

$ MSYS2_ARG_CONV_EXCL='/CN' openssl req -new -subj "/CN=foo" -addext "subjectAltName = DNS:foo.co.uk" -addext "certificatePolicies = 1.2.3.4" -key ./userkeys/user_device_priv.pem -out ~/req.pem

# Also works OK.