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

["Jarle Greipsland via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/59896; it has been noted by GNATS.

From: Jarle Greipsland <jarle.greipsland%norid.no@localhost>
To: gnats-bugs%netbsd.org@localhost, gnats-admin%NetBSD.org@localhost
Cc: netbsd-bugs%netbsd.org@localhost
Subject: Re: bin/59896: tr extends string2 incorrectly when [#*0] is
 specified
Date: Sun, 11 Jan 2026 15:57:57 +0100 (CET)

 "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."