Path argument changed by jq

[Incognito357]

Describe the bug
Passing a linux-style path as an argument results in a windows-style path being returned.

To Reproduce
Case 1:

echo "{}" | jq --arg a '/opt/' '.|$a'
"C:/tools/Git/opt/"

Case 2:

echo "{}" | jq --arg a '/c/dev/' '.|$a'
"C:/dev/"

Expected behavior
Expected the original argument to be used as-is, and not modified at all.
Case 1: Expected result to be "/opt/"
Case 2: Expected result to be "/c/dev/"

Environment

• OS and Version: Windows 10, running from git bash
• jq version 1.6

Additional Information
Passing the argument value with single or double quotes does not change the behavior.

[srenatus]

Passing the argument value with single or double quotes does not change the behavior.

Because what jq sees is the string inside the quotes; the quotes only matter for the shell, I think.

In a similar way, I don't think jq ever sees /c/dev/, because the shell running under windows is messing with that path before invoking the program. There's a similar issue here which points at these rules.

I have no way to try this, but from the document, I'd try this:

jq -n --arg a '/c/dev/;' '$a'

and try to figure out a way to deal with the trailing ;... 🤔

---

Btw, you can pass -n to have jq not need any input, e.g.

$ jq -n --arg a /c/dev '$a'
"/c/dev"

[Incognito357]

Thanks for the -n hint 😃

I wasn't sure the issue was something happening before jq or in jq, so the quotes were an attempt to prevent the shell from messing with it. I had no idea mingw was converting paths outside the scope of the shell, depending on whether the command being called was 'native' or not.

For any executable not dependent on msys-1.0.dll

Maybe there is a way to compile jq so it can be used by gitbash/mingw more 'natively' (kind of like the nano port)? I'm not sure if simply linking the dll would fix this issue, or if it would cause other compatibility issues.

In the meantime, I was able to work around the issue by passing the value wrapped with --argjson, and referencing the value: jq -n --argjson a '{"b": "/c/dev"}' '$a.b'. In my case, it actually worked out better this way, since the value was getting wrapped anyway, I could just reference as $a.

[srenatus]

Would switching to WSL be another workaround?

[linquize]

Msys Bash will convert Unix-style path to Windows-style.

Add environment MSYS_NO_PATHCONV=1 to supress path conversion.

It is not related to jq.

[Incognito357]

@srenatus In my work environment, that's not an option. It might solve the issue, though, I'm not sure.

@linquize
It's related to jq in that jq doesn't support msys, which is what causes msys to think it needs to convert the path (according to what I can gather from the rules @srenatus linked to). Is it out of the question to add support for msys, to build a windows exe that is treated more like a native linux binary? Changing the environment variable is an option, but it may cause issues with other programs that could rely on the conversion. In jq's case, I don't think it needs to rely on the conversion, especially since it's already built to be cross-platform.

I guess a wrapper script could be created to set the environment variable, call jq, then unset the variable, but that's a bit cumbersome.

[nicowilliams]

@Incognito357 we don't currently support msys. Does the msys shell really inspect the program you're executing to decide if it needs path arguments to be converted?? and it somehow decides that some argument is intended to be a path??

[Incognito357]

@nicowilliams I never would have thought this was happening either, until I ran into this issue, and srenatus pointed me to the msys documentation saying that it's doing so intentionally. The rules it uses for converting paths are clear, and appear to only inspect an argument as-is, which is why wrapping the parameter in a json object is left alone. I'm not sure how msys checks if an exe depends on msys-1.0.dll, but that's how it determines that it should attempt to convert paths that it finds in the arguments.