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' binary.) 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 Chris.Knadle@coredump.us
Attachment:
signature.asc
Description: This is a digitally signed message part.