#1012545 coreutils: unexpand: nonconformantly (to both POSIX and heirloom) replaces single spaces with tabs

Package:
coreutils
Source:
coreutils
Description:
GNU core utilities
Submitter:
наб
Date:
2022-06-11 00:36:03 UTC
Severity:
normal
#1012545#5
Date:
2022-06-08 23:09:46 UTC
From:
To:
Dear Maintainer,

  printf 'a  b' | unexpand -t1 | cat -A
  printf 'a  b' | unexpand -t2,3 | cat -A
both yield
  a^I^Ib
and
  printf 'a  b' | unexpand -t2 | cat -A
yields
  a^I b

According to 4.2BSD:
  If the -a option is given, then tabs are inserted whenever they would
  compress the resultant file by replacing two or more characters.
of course, heirloom unexpand doesn't take tab lists,
but this is still wrong according to Issue 7
(quoth IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008)):
  In addition to translating <blank> characters at the beginning of each
  line, translate all sequences of two or more <blank> characters
  immediately preceding a tab stop to the maximum number of <tab>
  characters followed by the minimum number of <space> characters needed
  to fill the same column positions originally filled by the translated
  <blank> characters.

The correct output for all three is, of course
  a  b
(NetBSD and the illumos gate agree;
 FreeBSD is broken even more, but that's unrelated).

Best,
наб

#1012545#10
Date:
2022-06-09 17:16:09 UTC
From:
To:
Similar case but I think slightly different:
  printf ' ermrxsmg \tjrjc ngsoo\n' | unexpand -t2          | cat -A
  printf ' ermrxsmg \tjrjc ngsoo\n' | unexpand -t4,55,68,78 | cat -A
output
  | ermrxsmg^I^Ijrjc ngsoo$
  | ermrxsmg^Ijrjc ngsoo$
whereas the correct output is
  | ermrxsmg ^Ijrjc ngsoo$
  | ermrxsmg ^Ijrjc ngsoo$

Fortunately, as in the OP, both correctly round-trip through expand as
  | ermrxsmg   jrjc ngsoo$
  | ermrxsmg                                              jrjc ngsoo$

наб

#1012545#15
Date:
2022-06-11 00:33:48 UTC
From:
To:
Hi!

The case described in the OP is still wrong though :)

Best,
наб

[1]: https://www.mail-archive.com/austin-group-l@opengroup.org/msg09780.html