bug#46422: 'pr' screws up tabstops in multicolumn outpt?

[Leonard Janis Robert König]

Hi,

On Thu, 2021-02-11 at 16:45 +0100, Erik Auerswald wrote:
> Hi,
> 
> On Thu, Feb 11, 2021 at 04:12:54PM +0100, Leonard Janis Robert König
> wrote:
> > On Thu, 2021-02-11 at 13:00 +0100, Erik Auerswald wrote:
> > > On Wed, Feb 10, 2021 at 01:42:29PM +0100, Leonard Janis Robert
> > > König
> > > wrote:
> > > > I'm sorry if I this is not a bug but to be expected, but I thnk
> > > > pr
> > > > doesn't get the alignment of tabs in multicolumn output right.
> > > > [...]
> > > > This seems *kind* of related to multi-column merged output, as
> > > > was
> > > > discussed some years ago here:
> > > > https://lists.gnu.org/archive/html/bug-coreutils/2007-03/msg00121.html
> > > 
> > > This thread contains the bug-introducing patch in message
> > > https://lists.gnu.org/archive/html/bug-coreutils/2007-03/msg00160.html
> > > 
> > > This is commit 553d347d3e08e00ee4f9df520b37c964c3f26e28.
> > 
> > ah, thanks for digging, I read the message but must have missed
> > the patch.
> > 
> > > That commit removed the 'assume -e' part of the POSIX description
> > > of the -COLUMN option from GNU pr.
> > 
> > Which is definitely against POSIX yeah.  The problem however, is
> > not
> > POSIX, but that the test case would succeed on a POSIX confirming
> > implementation, despite -e being assumed.  The process should be:
> > 
> > 1. read in while untabify input (-i)
> > 2. write out while (re-)tabify output (-e)
> 
> The options are the other way around: -e expands tabs while reading
> input,
> -i unexpands spaces on output.

Ah, yes, but the same thought applies.

> Your test case requires expanding tabs
> during input, which is the reason that "expand | pr" could be used as
> a
> workaround (with "expand | pr | unexpand", pr would not need to mess
> with
> tabs at all, but I do think that GNU pr is currently buggy and should
> be fixed).

Absolutely, expand would be a workaround (I happen to use `pr -e | pr`
in my script, for other reasons).

I've looked a bit further through the code but there's hardly a single
place that needs to be touched in order to not introduce other bugs
again.  For now I can only put it on my to-do list to fix, but no idea
when I get around doing it.

~leo

> P.S. Feel free to re-add the bug tracker / list email address if you
> like.

P.P.S:  Yeah, I should configure my mailer to warn if I don't answer
everyone.