Date: Sun, 12 Jan 1997 17:38:23 +0200 (IST) From: Eli Zaretskii To: Dave Pearson cc: djgpp AT delorie DOT com Subject: Re: Off behaviour with 'cat -b' In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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).