SlickEdit Community
Archived Beta Discussions => SlickEdit 201x Beta Discussions => SlickEdit 2017 v22 Beta Discussion => Topic started by: acg on September 19, 2017, 01:58:16 PM
-
"Support for reading .gz files without decompressing them first"
This right there is the reason I jumped on this beta today. Unfortunately, I'm unable to get it working. Is there anything I need to toggle on? Or are there version limitations?
Thanks.
This is the version information for what we're using:
gzip -V
gzip 1.4
Copyright (C) 2007 Free Software Foundation, Inc.
Copyright (C) 1993 Jean-loup Gailly.
-
Ah... there's something non-obvious you need to do.
First, use the open tool window. If you have a file called test.gz. Type test.gz/test. Then you can open the file. It treats it like a zip or tar file (like a directory).
I can't remember if we put in an option to auto crack open a .gz file. We will look into this.
-
When you do a multi-file find, you can check the "Look in zip/word/excel files" check box and it will also traverse .tar and .gz folders due to the way SlickEdit treats them as directories.
-
I'm opening the file via the FTP window (to our WAS hosts to pull the logfiles that get gzipped after a few days). I don't use the normal file open dialog at all.
That said, this is still an improvement of my current process:
- pull file via FTP
- Alt-Z (brief keymap) to open a command shell (to the current buffer directory)
- start . (to open file explorer)
- right-click the GZ and unzip it
- right-click the logfile and SendTo SE
- discard the gz buffer to release the local copy of the file
This new feature will eliminate a couple of those steps, at the cost of making me type out the logfile name twice (logfile.log.gz/logfile.log).
Tighter integration to the buffer load (auto-explode) would be nifty. Of course, my use-case of one file per gz is a lot simpler than n-files per gz.
-
I added an option for automatically decompressing .gz files for the next build. It will work for FTP. It's on by default. However, it will be off for you if you have an existing configuration. Go to Tools>Options>File Options>Open and turn on "Decompress .gz files on open".
This should be really convenient for you.
-
Just got to trying this today. If I open a .gz up directly, I get prompted for the "create the file" and then it fails to open (either using File Open or SendTo). File Open generates the warning in the lower right, "Error opening file. Path not found". If I open via the FTP window, I get "Unable to open local file <filename>. Path not found"
I'm trying to open the same file over and over, and I'm being prompted to create the same file over and over, which suggests the file isn't being created. I created a file in the same directory (edit new file name, type in something, save) and that worked fine, so it's not a simple permissions issue.
It looks like it's trying to create the file under the gz (i.e., "<slickedit-ftp-path>\logfile.log.gz\logfile.log"). I only noticed that after creating the target filename expecting to no longer be prompted for "create the file".
-
What happens if you try to open the attached .gz file using File->Open?
-
Create File prompt for junk.cpp.gz\junk.cpp and then Warning, Error opening file: File not found.
SlickEdit Pro 2017 (v22.0.0.5 64-bit)
-
I tried Windows and Linux and both work for me. No idea what's different.
Try a default config: vs +new -sc <new-config-dir>
-
Same with a new configuration.
Oh well, appreciate the attempt. If I can narrow down the problem any, I'll post.
-
Are you still using FTP? These tests were supposed to be without ftp involved. Just to test the basics.
-
Just using File Open. I assumed you were also testing the gz version, in case that was a variable factor.
-
I used the file open dialog and selected "junk.cpp.gz" from the list. I've tested other ways and they worked too.
-
Tried it on my home machine, fresh install, previous version installed 2015 (whoops). No prompt to create the file, but still the same file not found warning.
-
When I open junk.cpp.gz with v20 or v21, SlickEdit opens the file in Hex mode.
Do you have some sort of driver installed which messes with .gz files?
-
WinZip is installed and associated to .gz.
-
Also, if I turn off "Decompress .gz files on open" in v22, it opens in Hex mode.
If I select "Save as new file" rather than "Create the file", nothing happens. "Create the file" gives the file not found error. What if the exploded file were put in the directory with the .gz rather than under it?
-
No effect for me. Some of the test cases I did, I already had the file decompressed in the same directory as the .gz file.
At least we know the "Decompress .gz files on open" option is taking effect.
-
There has got to be something different about the configuration of your machines.
-
Could it an antivirus program or similar interfering? I'm not sure why an AV would block access to .gz files, but the behavior kind of sounds like the random problems that can occur when an AV decides it doesn't like something: just cause a failure without any notice about why or that the AV is involved at all.
If this was happening on Linux I'd suggest using strace to figure out why the failure is occurring (or at least whether or not it's happening at the system level). But the closest thing to that on Windows I can think of is the SysInternals procmon utility, and it didn't play well on my computer the last time I tried so I'm not sure I can suggest it.
-
Good points. I'm pretty sure he's on Windows.