I like trying out new things quite frequently and often times these tools are packed in an archive file. But I’m in constant fear whenever I am to unpack those archives because sometimes there are hundreds of files and the person who packed them wouldn’t even do the bare minimum of nesting them inside a directory.
Dolphin (file explorer) had a useful thing where it would detect whether the contents are already nested and if they are not only then it would nest them inside a directory. I tried searching for something similar for the CLI but couldn’t find anything so here it is. Another benefit is that it supports .zip, .tar.xz, .tar.gz simultaneously so I don’t need to deal with manpages of unzip, tar thousand times just because I keep forgetting how to use them. Now it’s just vert x file.zip.
I can add support for a few more formats but I don’t feel the need at least for now (PRs welcome).
So it detects if there’s a single folder inside the zip containing all the files or all the files directly inside the zip? That’s useful!
Reminds me of Minecraft texture packs back in the day where nobody really understand how to make a texture pack and all used Ms paint and this was a common issue as clicking “add to .zip” on the folder would make a containing folder and not work. This would mean each user would have to extract it and have folders in their resource pack folder instead of zips.
This… worked, but when the client(basically a large QOL mod) ~50% of people used added the ability to put texture packs in folders to organize them it treated the unzipped packs like a folder so they stopped working.So it detects if there’s a single folder inside the zip containing all the files or all the files directly inside the zip?
Yes. It also has
l(lowercase L) subcommand which lists the contents of the archives to the terminal (stdout).but when the client(basically a large QOL mod)
I think you a word. Did you mean when the client updated?
There’s enough words there - I read it as “when this widely-used client added feature x”…
Ah you’re right. I was expecting the word update or something after client.
It’s definitely a bit of a confusing garden-path sentence.
Warning
Never extract archives from untrusted sources without prior inspection. It is possible that files are created outside of path, e.g. members that have absolute filenames starting with “/” or filenames with two dots “…”.
https://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extractall
I would be careful if using this as a general purpose tool.
A better alternative would likely be to use the regular command-line tools which have been hardened to this type of thing (and are likely much faster) and then just inspect the result. Always create a wrapper directory, then if the result is only one directory inside of that move it out, otherwise just keep the wrapper. I would recommend that the other updates their tool to do this rather than the current approach.
UPDATE: Implemented
VERT_USE_EXTERNAL_TOOLSenvironment variable. See #Configuration.I had passed the
filterparameter as"data", which should help prevent most issues with it but yes I agree that it would’ve been better to use external tools to do the heavy-lifting. I avoided them to make the program cross-platform and easier to setup (you currently can just run a simplepipcommand to install it). I may introduce them as optional backends later with a warning on the default ones but for now I’m postponing it.
Good luck with the project.
I want to request a not-feature: One time I extracted an archive with an odd command that ended up dumping all its contents without directories straight into the base folder of the archive without a way to undo that. Please don’t make that possible with your tool. 😂
I had to manually clean up the directory.
Vert guarantees a single file/directory when you extract something with it. If there are more than 1 file in the archive it will nest them in a directory. I have no plans to add any flags or anything to make it extract without nesting either.
Unzip tools should always do it in a new folder.
I can deal with home/ZipName/ZipName. I have no patience whatsoever for a program dumping randomly-dated files onto an existing directory.
Do the simplest thing that could possibly work.
Very nice! This is definitely an annoying problem.
I’m not trusting this to Python though.
