bug#52033: a bug in paste command

[Visser, Gerard]

Hello,
My apologies for the false bug report, you are quite right and I should have 
thought of this possibility. Burned again by naively taking files from Windows 
systems. Oh well.
Thank you for taking the time to point this out, I will be more careful in 
future. Please close the case.
Sincerely,

      Gerard


________________________________
From: zsugabubus@national.shitposting.agency 
<zsugabubus@national.shitposting.agency>
Sent: Monday, November 22, 2021 4:42 AM
To: Visser, Gerard <gvisser@indiana.edu>
Cc: 52033@debbugs.gnu.org <52033@debbugs.gnu.org>
Subject: Re: bug#52033: a bug in paste command

Hi,

On Mon, Nov 22, 2021 at 05:23:33AM +0000, Visser, Gerard wrote:
>   Hard as it is for me to believe, it seems I have uncovered a bug in the 
> paste command. I got unexpected/incorrect results in the course of my work 
> (which I can describe as merging two data files from some electronic test 
> equipment for the purposes of analysis and plotting). Attached is a tarfile 
> of a test case with two files and a log showing the incorrect results and the 
> version info of paste.
>    I hope this email will reach the right people to investigate this.
>     If it is a known issue and there is a workaround for me to use, please do 
> let me know.

It is only your terminal emulator that tricks you: Your file contains
carriage returns that moves cursor to the first column, so that next
line will appear on top of the previous.

$ file e f
e: ASCII text, with CRLF line terminators
f: ASCII text, with CRLF line terminators

If you do `paste e f | cat -A`, you can see it yourself what's going on.
Use `tr -d '\r'` to remove unwanted CRs.

--
zsugabubus