Re: [patch] cat -n bug from 33 years ago

[Crystal Kolipe <kolipe.c%exoticsilicon.com@localhost>]

On Sat, Nov 18, 2023 at 02:24:48PM -0500, Mouse wrote:
> >>> Numbering currently starts over at 1 for each input file [...]
> >> If you want to have continuing (non-restarting) numbering for
> >> multiple input files, one could use "cat file1 file2 | cat -n".
> > True, that would be a workaround.
> 
> > But shouldn't the current behaviour still be fixed?
> 
> First, I think, we should decide whether "fixed" is an appropriate
> word.  Perhaps it's just me, but I don't consider Linux cat to be a
> reference implementation.  (Indeed, I don't consider the Linux
> implementation of pretty much _anything_ to be a reference, except for
> Linux-specific things.)

Well I said 'fixed' because it would be reverting to the way it worked
in the oldest BSD versions that I've looked at.  Generally before 4.3,
the line number counter was a global variable 'lno' and it was only
initialised to 1 once at the start.  4.3-Reno seems to be where it was
changed to a local variable 'line' in cook_buf(), and that version has
survived in to the modern BSDs.  The lack of any mention in the manual
makes me think that it wasn't an intentional change.

I've since noticed another related issue, this time with -s, which is
supposed to replace multiple empty lines with a single one.

$ echo "foo\n\n\n" > 1
$ echo "\n\n\nbar" > 2
$ cat -s 1 2
foo


bar

Whereas on 4.2BSD, the empty line at the end of 1 and the empty line
at the start of 2 are in fact collapsed:

$ cat -s 1 2
foo

bar

If nothing else, it's interesting that functionality can change after
ten years and then go 30 years with nobody noticing :-/.