Ben Walton <> writes:

> Solaris' tr (both /usr/bin/ and /usr/xpg4/bin) fail to handle the case
> where the first argument is a multi-character set and the second is a
> single null character.

Almost all the tr invocations look like converting LF to NUL, except
for two that squash a colon ':', HT and LF all to NUL.  Is Solaris's
tr fine with the former but not the latter?

> We make this change globally in t0008-ignores instead of just for the
> cases where it matters in order to maintain consistency.

I am not suggesting to keep 'tr "\n" "\0"', but just wanted to make
sure I am reading the first paragraph correctly.  If we are
rewriting, we should do so consistently.

> +perl -pne 's/^"//; s/\\//; s/"$//; s/\n/\0/g' stdin >stdin0

What is -pne?  Is it the same as -pe?

tr/\n/\0/ (or y/\n/\0/) may be more faithful to the original.

> +perl -pne 's/^"//; s/\\//; s/"$//; s/\n/\0/g' expected-default > \
> +    expected-default0

Ditto.  We may want to give the same script used in the above two
(and twice again in the later hunk) more descriptive name, e.g.

        broken_c_unquote () {
                perl -pe '... that script ...' "$@"

        broken_c_quote stdin >stdin0

Side note: the script is broken as a generic C-unquote function in
multiple ways.  It does not work if it has more than one backslash
quoted characters, it does not understand \t, \b, \015, \\, etc. to
name two.

But the breakage does not matter for the strings used in the test
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to