Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: Another possible kernel enhancement...
Message-ID: <19072@rpp386.cactus.org>
Date: 25 Feb 91 13:43:23 GMT
References: <654@uswnvg.UUCP> <19069@rpp386.cactus.org> <1183@amix.commodore.com>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 24
X-Clever-Slogan: Recycle or Die.

In article <1183@amix.commodore.com> ag@amix.commodore.com (Keith Gabryelski) writes:
>In article <19069@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II)
>>The solution is to permit the "\" character to function as a line
>>continuation character on input, and add "\" characters on output.
>
>A more general solution is to fix the bug that prevents the program
>from correctly dealing with sufficiently long lines.

Agreed.  However, this has a dependency on fixing every program which
might ever have anything to do with text files.  It isn't just that
getgrent() can't handle arbitrary length lines - but neither can a
whole slew of other commands that don't rely on getgrent() for their
input.

>Ps, This is not to say that line continuation characters are evil but
>they should be unnecessary.

Regrettably they are quite necessary because so many other UNIX commands
don't properly handle lines of arbitrary length.  ;-(
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"I've never written a device driver, but I have written a device driver manual"
                -- Robert Hartman, IDE Corp.


Brought to you by Super Global Mega Corp .com