[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /usr/share/doc/ files and gzip/xz/no compression

On Monday, August 15, 2011, Russell Coker wrote:
> On Tue, 16 Aug 2011, Chris Knadle <Chris.Knadle@coredump.us> wrote:
> > > After all, it isn't called gzless.
> > 
> > Actually, that's not far off.  Right now these functions are
> > spread across 4 different binaries, each of which is in a
> > different package.
> Probably the best thing to do would be to just incorporate the
> functionality in the less package.
> zless works with uncompressed files and is well known to work that
> way.  I'm sure that lots of people run "zless *" without regard to
> whether there are compressed or uncompressed files in the
> directory.

I commonly do that.  Not just with zless but even more commonly with 
zfgrep.  [And this hints that this issue is larger than just 'less'.]

Apparently bzmore and xzless are likewise able to read plaintext 
files, so these binaries are also doing file type recognition.

> Having zless and less do the same thing and support a
> wide variety of compression methods would be ideal.  It's not as
> if anyone would use less to view the binary contents of a gzip
> data stream.

I think you're onto a good idea.

It seems like it should be possible to build one 'less' such that it 
will read all of the compressed file types, and have zless xzless and 
bzless all point to 'less' via softlinks.  (Or hardlinks, if they're 
in the same directory, similar to how used to be done with separate 
'git-<thing>' binaries after they were consolidated into one 'git' 

I'm trying to think of what undesired effects this might have.

One unexpected consequence would be that calling 'less' by default 
wouldn't skip over compressed file types that it would know how to 
handle.  If it were desired to be able to skip over compressed files, 
'less' could be crafted to change behavior based on the filename that 
was actually called (as was likewise done with git), thus zless bzless 
and xzless would open compressed files, but 'less' itself could avoid 
doing so.  Or add yet another command-line option as to whether to 
open compressed file types or not.

  -- Chris


Chris Knadle

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: