Re: bin/59896: tr extends string2 incorrectly when [#*0] is specified

[Jarle Greipsland <jarle.greipsland%norid.no@localhost>]

"RVP via gnats" <gnats-admin%NetBSD.org@localhost> writes:
>  On Wed, 7 Jan 2026, jarle.greipsland%norid.no@localhost via gnats wrote:
>  > The man page states:
>  > ... If n is omitted or is zero, it is interpreted as
>  >    large enough to extend the string2 sequence to the length of
>  >    string1.  If n has a leading zero, it is interpreted as an
>  >    octal value; otherwise, it is interpreted as a decimal
>  >    value.
>  >
>  It seems to me that this says `[q*]' will extend `string2' to the remaining
>  length of `string1' first, then `x-z' will get tacked on, exceeding len. of
>  `string1', and therefore will not be used.
I guess that is a valid interpretation of the text.  Although not
the first one that came to mind, for a non-native speaker of the
English language.

>  > It seems like NetBSD's tr does not take into account any characters
>  > in string2 found after the [#*n] expression.
>  >
>  But, should it?
Good question.  It adds a capability to the utility (but possibly
a fringe capability or one that is not wanted or is confusing).
The behavior following from your interpretation can otherwise be
acheived by specifying a short string2, and rely on the
documented behavior where "the last character found in string2 is
duplicated until string1 is exhausted."

>  > GNU tr from coreutils behaves as I would expect:
>  > $ echo A N Y | gtr A-Z 'a-c[q*20]x-z'
>  > a q y
>  > $ echo A N Y | gtr A-Z 'a-c[q*0]x-z'
>  > a q y
>  >
>  
>  GNU tr(1) seems to be the only one which does this. Both OpenBSD and FreeBSD
>  tr behave like NetBSD's; as does the tr in OpenIndiana 2025.10.
Score one for conformity and predictability, I guess.

					-jarle
-- 
"My poor knowledge of Greek mythology has always been my Archimedes heel."