Allow \0 escape for nulls

[Dr-Emann]

This allows safely getting e.g. multiple descriptions, and knowing where the boundaries are

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have added tests to cover my changes
• N/A I have updated the documentation (README.md, docs/, demos/)
• N/A I have updated the config schema (cli/src/config-schema.json)

[martinvonz]

Thanks!

[ilyagr]

Interestingly (er... to me), the following doesn't seem to print any null characters:

$ jj log -T $(printf '"a\0b"')

In fish, I also get:

fish> jj log -T '"'a \0 b'"'
Error: Failed to parse template:  --> 1:3
  |
1 | "a
  |   ^---
  |
  = expected escape or raw_literal

Meanwhile, this does work.

$ jj log -T $(printf '"a\1b"')

So, it makes sense to add "\0" and not "\1".

Update: This is a shell issue. I managed to get the templater to parse a raw null char by adding the following to my TOML config. I don't think this possibility does much to subvert the point that entering a null byte without this PR is a little difficult.

[template-aliases]
tmp_null = "\"a\u0000\u0001b\""

[yuja]

If you like, you can update test_string_literal() in template_parser.rs. I think it's also good to have e2e test since null character is a bit special, so I wouldn't remove all of the CLI tests.

[Dr-Emann]

Interestingly (er... to me), the following doesn't seem to print any null characters:

$ jj log -T $(printf '"a\0b"')

I believe it's actually impossible to pass a real null byte as a parameter: parameters are null-terminated strings all the way down to the exec syscalls. Presumably, bash is stripping out the null, and fish is probably actually setting the parameter exactly as the string you specified, and so ends up terminating the parameter early at the exec call.

[Dr-Emann]

Added to test_string_literal as well