#1035534 coreutils: pr: -s broken entirely?

Package:
coreutils
Source:
coreutils
Description:
GNU core utilities
Submitter:
наб
Date:
2023-05-05 01:30:04 UTC
Severity:
normal
#1035534#5
Date:
2023-05-05 01:27:26 UTC
From:
To:
Dear Maintainer,

POSIX says (lines 1003.1-202x/D3):
-- >8 --
110789  −s[char]  Separate text columns by the single character char instead of by the appropriate
110790            number of <space> characters (default for char shall be <tab>).

110817  LC_CTYPE  Determine the locale for the interpretation of sequences of bytes of text data as
110818            characters (for example, single-byte as opposed to multi-byte characters in
110819            arguments and input files) and which characters are defined as printable (character
110820            class print). Non-printable characters are still written to standard output, but are
110821            not counted for the purpose for column-width and line-length calculations.
-- >8 --

So how does this map onto
-- >8 --
% pr -w22 -2 -s | cat -As
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
$
2023-05-05 03:16  Page 1$
$
abcdefghijkabcdefghijk$
$
% pr -w22 -2 -s'	' | cat -As
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
$
2023-05-05 03:16  Page 1$
$
abcdefghij abcdefghij$
$
-- >8 --
(that's a literal tab in the second one).

Not only ought these to be the same,
in the first one the separator is lost,
and in the second it's turned into a space.

The correct output for both is, naturally,
  abcdefghijk^Iabcdefghijk$

Oddly, specifying -sQ behaves as expected.

Best,
наб