Choose line endings

[ghost]

On the Windows version at least output lines are ended with carriage return newline CRLF, which is of course the Windows default.

However this can cause havoc for Windows users with Cygwin or MinGW, as those systems rely on lines to end with newline LF only.

Perhaps a command line switch could be made to enable LF line endings. As a workaroud, you can use:

jq --join-output

jq -j

[stedolan]

jq doesn't mangle line endings on its own, it just tells the C library to print '\n'. The Cygwin C library seems to interpret this as "print CRLF". I think (although it's been a while since I've used Cygwin) that you can configure cygwin to not do this.

If all else fails, we can add an option to get jq to open files in binary mode. This seems like the wrong thing to do, though - I think you should be able to fix this by modifying your cygwin config. That would fix it for programs other than jq as well.

[stedolan]

This definitely seems to be Cygwin's problem, not jq's. There's a bunch of ways around this on http://cygwin.com/cygwin-ug-net/using-textbinary.html

[frou]

Or pipe into tr to turn CRLF into just LF:

jq . x.json | tr -d '\r'

[hackery]

http://cygwin.com/cygwin-ug-net/using-textbinary.html says that

Pipes, sockets and non-file devices are opened in binary mode.

but I'm seeing CRLF in piped output in MinGW64, so there may be something else to consider here.

[mehrdadn]

Hi @stedolan, I think this issue is still unresolved. I think there is a confusion between the line endings that are used in raw mode and outside raw mode.

For example, if you type the following into the Command Prompt

echo "[\n]" | jq -r .

the string between the brackets must not contain a carriage return under any platform.
It would be wrong to blindly output this \n into text-mode stdout and have it transformed into \r\n; it's actually binary data that must be passed through as-is. Currently, this is a bug.

There is a second issue here, which is that this command produces an extra trailing newline.
As far as I can see, this line ending should not exist at all—it is clearly not part of the raw data.
However, if there is some justification for its existence, this line ending should be platform-specific, i.e. CRLF on Windows. (Or, if in e.g. binary mode, LF.)

These are significant issues because it is extremely important for the user to be able to perform a perfect decoding of the contents of JSON strings. Any transformations can mess things up. However, the way things are currently, I have to resort to Python for this task, because with jq I can't find any way to be sure it's not mutating the string contents.
It's rather unfortunate as this is possibly one of the most basic tasks one could possibly perform with jq, so if you might be able to look into fixing it, that'd be awesome. Thank you!

[mirabilos]

This is really a problem when using the stand-alone jq-winXX.exe under cmd (batch scripts) where Unix tr(1) is not available. This is almost killing jq for me.

[mirabilos]

We cannot use -j either. Trying to write "\u000A" under jq for Windows produces CRLF, too 😠

[bukowa]

If anyone landed here and had the same problem, I solved it by using the -b flag.