Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!columbia!douglass!dupuy
From: dupuy@douglass.columbia.edu (Alexander Dupuy)
Newsgroups: comp.sources.bugs
Subject: Re: less5 - 2 fixes and an enhancement...
Message-ID: <5917@columbia.edu>
Date: 30 Sep 88 16:15:07 GMT
References: <1396@zen.co.uk> <12247@steinmetz.ge.com> <198@ispi.UUCP>
Sender: news@columbia.edu
Reply-To: dupuy@douglass.columbia.edu (Alexander Dupuy)
Followup-To: comp.sources.bugs
Organization: Columbia University Computer Science Dept.
Lines: 27

In article <12247@steinmetz.ge.com>, davidsen@steinmetz.ge.com writes:
> Also, as useful as the ability to read some compressed file formats is,
> I would rather keep less small and use the appropriate utility piped
> into less when needed. (That's an opinion)

In article <198@ispi.UUCP>, jbayer@ispi.UUCP agrees.

I have to differ on this.  While I agree with the philosophy of keeping the
functionality of less limited to displaying text files, if either of you had
looked closely at the posted code, you would see that it does exactly what you
would be doing manually, i.e. using the appropriate utility piped into less.

There is a pretty good tradition of having one unix utility forking off another
to do part of its work; find -cpio, Gilmore's pdtar -z (which uses uncompress
in exactly the way the less patches do), to name the first which come to mind.

The only argument against the patches which I would concede has any validity is
the law of least surprise - normally, piping the output of less (or more)
reduces its functionality to that of cat.  But I think the advantage of being
able to read compressed files directly, _regardless of compression format_,
outweighs the arguments against.

@alex

-- 
inet: dupuy@columbia.edu
uucp: ...!rutgers!columbia!dupuy