jo will drop the trailing newline at the end of file

[tw4452852]

> echo foo > test.txt
> jo 'test=@test.txt'
{"test":"foo"}

The manual says:

@file substitute the contents of file as-is

Why the trailing newline is stripped when processing? I expect jo should leave the content string the same as the file content.
BTW, the code is here:

jo/jo.c

Line 350 in b3e67e1

if (*bp == '\n') *bp-- = 0;

[jpmens]

It made sense to me/us to have that stripped.

Why would you not want it stripped?

[jpmens]

We should probably amend the description in the man page.

[tw4452852]

But I want to make a json with the exact content of a file as it-is. Could I archieve this with jo? Maybe we could add a option (like -raw)?

[jpmens]

The only solution which occurs to me right now is to transport with base64 and then decode on the receiving end:

$ echo hello > test.txt
$ jo 'test=%test.txt'
{"test":"aGVsbG8K"}
$ echo aGVsbG8K | base64 -d
hello
$ echo aGVsbG8K | base64 -d | od -cb
0000000    h   e   l   l   o  \n
          150 145 154 154 157 012
0000006

[tw4452852]

Really hope jo could add an option to support reading the raw content of a file as a string.

[isotopp]

It made sense to me/us to have that stripped.

Why would you not want it stripped?

It would invalidate any checksum or signature on the content of that file.

[gromgit]

Since trimming the output has been the default operation for years with no complaints until now, it might not be desirable to unilaterally switch to verbatim inclusion mode by default.

I guess we could add a -l (for literal) switch, and document current behavior.

[jpmens]

I'm not hugely in favor of a switch to toggle that behaviour. Would a separate character make sense? <filename, reminischent of shell input.

BTW, if we do implement this, the underlying JSON routines will not handle binary zero \00, so I'm not sure how useful this would be.