I've had an unwritten goal to always produce 7-bit ASCII.
Recent changes to Sh have unavoidably broken that because Dash has no escape syntax for high bytes. Pure binary data quoted/escaped by Sh must still be treated as (mostly) pure binary data – it is not safe to convert quoted output produced by Sh into &str or String for example – but the quoted output from Bash or Fish is safe to treat as text; it's always UTF-8.
Indeed, recent changes in #21 have also broken the 7-bit ASCII rule for Bash and Fish because UTF-8 for code points of U+0080 and above is copied verbatim into the output. It's possible to stick to 7-bit ASCII by encoding text into a byte-like form, like &[u8], before quoting, but this API has a sense of indirectness, action at a distance.
It could be useful to have an option to ask for 7-bit ASCII output regardless of the input.
In any case, this crate should state the 7-bit ASCII goal explicitly in documentation, and back it up with explicit tests.
I've had an unwritten goal to always produce 7-bit ASCII.
Recent changes to
Shhave unavoidably broken that because Dash has no escape syntax for high bytes. Pure binary data quoted/escaped byShmust still be treated as (mostly) pure binary data – it is not safe to convert quoted output produced byShinto&strorStringfor example – but the quoted output fromBashorFishis safe to treat as text; it's always UTF-8.Indeed, recent changes in #21 have also broken the 7-bit ASCII rule for
BashandFishbecause UTF-8 for code points of U+0080 and above is copied verbatim into the output. It's possible to stick to 7-bit ASCII by encoding text into a byte-like form, like&[u8], before quoting, but this API has a sense of indirectness, action at a distance.It could be useful to have an option to ask for 7-bit ASCII output regardless of the input.
In any case, this crate should state the 7-bit ASCII goal explicitly in documentation, and back it up with explicit tests.