https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287615
--- Comment #19 from Jamie Gritton <[email protected]> --- It's not that newline-separated values are unintuitive, just that setting an option to NUL-separate other things would also do this is not something anyone would expect without reading the code. With multi-values parameters, it seems escaping rears its ugly head no matter what. I'm willing to accept that parameter values won't have NUL, because the kernel is still a world of C-strings, and in particular jail_set(2) stops at NUL in the standard C fashion. But if you grant any other character meaning, it's back to escapes. Granted, you're not adding this requirement with newline-escapes; you're merely highlighting what was already true with commas. Nonetheless, single values can have newlines, and those newlines would need to be escaped in a multi-valued variable. So I was wrong about bypassing the escaping. Newlines (and thus backslashes) will need to be escaped to guarantee unchanged parameter values. jls(8) has this problem as well. Its has libxo to produce machine-readable output. Nothing like nul-newline-separation, but machine-readable nonetheless. Longer term, that may be the way out of this. Even longer term, it semantically makes more sense for jail -e to really be some option to jls, since you are in fact listing jails, just not substantiated ones. That would require rolling jail(8) and jls(8) into a single executable, possible along with jexec(8) which has some issues that would be best addressed by being config-aware. -- You are receiving this mail because: You are the assignee for the bug.
