Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Support reading gzipped files #122

Open
nickman opened this issue Aug 4, 2016 · 7 comments
Open

Feature Request: Support reading gzipped files #122

nickman opened this issue Aug 4, 2016 · 7 comments

Comments

@nickman
Copy link

nickman commented Aug 4, 2016

GZip encoding can be detected on file open.
I realize this may be a performance hit, but it would be extremely helpful.

@variar
Copy link
Contributor

variar commented Dec 2, 2016

I'd like this for all archive files because in our company logs are attached to bug-reports as zip/7z archives and having to unpack them before opening is pain :) However, I don't see how this can be achived using current line indexing.

@nickbnf
Copy link
Owner

nickbnf commented Mar 17, 2017

Indeed, this is highly desirable and I have been thinking about how to do that for a while. Indexing is fine as you can stream the file whilst indexing. The problem is the display, which is done by reading a small, arbitrary part of the file, this is difficult to do on a compressed file unless the compressor as put some marking in it. But I'm still trying to find a solution (which is not to decompress the file fully in memory!!)

@jleaders
Copy link

jleaders commented Jun 7, 2019

Might I suggest this interface:
You are a viewing a compressed file, would you like to decompress it? NOTE: This will disable realtime-streaming of this file, and will decompress in a temporary directory [Decompress]

If you push decompress, do nothing fancy other than unzip to tmp & open that in a new tab (Then popup an error if the tempdir write fails)

Then all these concerns about random access and performance is sidestepped in favor of a one-click, sensible interface.
Besides, realtime streaming is rarely needed for compressed files, they are usually archives.

Yes this will use disk space, but since it's by user request, it seems reasonable

@svogt
Copy link

svogt commented Dec 3, 2019

I would also vote for decompressing on the fly to a (configurable) temporary directory.

On Linux lograte often times produces gzipped log files (no archive, just gzipped) - I think that's the reason zless / zgrep exist ;)

@variar
Copy link
Contributor

variar commented Jan 3, 2020

Integrated to latest pre-release klogg build (20.1.0.562, see CI artifacts) a simple version of @jleaders suggestion. zip/7zip/tar.gz/tar.bz2/tar.xz are supported as well as gz/bz2/xz compressed files. Compression is determined by extension. Will use something like libmagic to actually look into file headers in next builds.

Would appreciate any feedback.

@jleaders
Copy link

jleaders commented Jan 4, 2020

Thanks for your great work! Any hope for it merging down into glogg?

@variar
Copy link
Contributor

variar commented Jan 4, 2020

There has been no activity in glogg repository since April 2018 :( That is one of the reasons my fork exists.

If @nickbnf is still interested in developing glogg, I will be happy to contribute. If not then finding new maintainer for this great peace of software might be an option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants