Date:	Sun, 12 Jan 1997 17:38:23 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Dave Pearson <davep AT hagbard DOT demon DOT co DOT uk>
cc:	djgpp AT delorie DOT com
Subject:	Re: Off behaviour with 'cat -b'
In-Reply-To:	<slrn5dcgqu.jsu.davep@hagbard.demon.co.uk>
Message-ID:	<Pine.SUN.3.91.970112172236.7675k-100000@is>
MIME-Version:	1.0

On Fri, 10 Jan 1997, Dave Pearson wrote:

> I wonder of anyone can comment on this?

I'm the one who did the port, so I guess I *should* comment.

> C:\>cat -b foo | cat
>      1  this is line 1
>      2
>      3  this is line 2
>      4  
>      5  this is line 3
> ----------------------------------------------------------------------
> 
> It looks as if the -b is ignored when you redirect or pipe the output.

It's the usual DOS/Unix text/binary files hassle.  Actually, `-b' is not
ignored.  You forget that an empty line created by "cat > foo"  isn't
really empty: there's a '\r' (CR) character before each '\n.  Now, the
DJGPP port of `cat' uses binary reads *unless* its output is a console
device (it's a long story why this is so, but if you are really
interested, I can tell the gory details which led me to that decision). 
So when writing to a pipe or a disk file, `cat' reads the file in binary
mode, sees a '\r' before a '\n' and decides that the line isn't empty.  
When the output is the console, the file is read in text mode, those 
'\r' characters are stripped away, and the lines seem empty.

If this really  annoys you, I think a hack specific to -b option 
can be introduced into `cat', but I'm not sure if it's worth the 
trouble.  A new version 1.21 of Textutils is out, so when I port it I 
will see what can be done here.  Thanks for reporting this.

> Testing this on my Linux box:

Linux (like every Unix system) doesn't distinguish between text and binary
files, and so `foo' there indeed has only a '\n' on each empty line. 

> One other thing I've noticed with cat (not tested it with anything
> else) is that if you are cating a large file and you press Ctrl-C,
> rather than breaking, it appears to go to the start of the file and
> re-starts the output again. Only when it gets to the end of the file
> do you get a "Exiting due to signal SIGINT". Is this correct
> behaviour?

No.  But if you see that in DOSEmu on a Linux machine, it can be 
something specific to the DPMI support in DOSEmu.  It works correctly for 
me on plain DOS and MS-Windows.  In general, Ctrl-C handling is broken in 
some DPMI hosts (another example is QDPMI).

- Raw text -