You must log in or register to comment.
I always just use
“eXtract Zee Files”
deleted by creator
Just use Ouch!
Check out atool
You also don’t need the dash for the short options.
Also, if you’re compressing with bzip2 and have archives bigger than a few megabytes I’ll like you a lot more if you do it with --use-compress-prog=pbzip2
You also don’t need the dash for the short options.
True, but I refuse to entertain such a non-standard option format. It’s already enough to tolerate
find’s.Technically the notation with dashes is the non-standard one - the dash form is a GNU addition. A traditional tar on something like Solaris or HP-UX will throw an error if you try the dash notation.
It’s also traditional to eat raw meat, but we discovered fire at some point.
Don’t try to take my raw ground pork away from me.
I got toxoplasmosis that way
my raw ground pork away from me.
Who are you, the Mett demon?
\(It works great with beef, too. Bonus points for the raw yolk over it. If not homemade though there’s literally one bar that I trust with this, salmonella is not fun.)
Not enough onions. Your average mettigel has better mett/onion ratio.
That’s an audible “yuck” from me, man. Well done!
Looks like you Mett your match.
Can’t be well done if it’s raw.
I like the dashes, they make the options look like options to me.
You also don’t need the dash for the short options.
You know when you meet someone and you’re just like “oh boy, yeah, they’re evil. No humanity at all”
ps aux says hi!
I think the
-jalso compresses with bzip2 but I’m not sure if this is defined behavior or just a shortcutYes, but I’m asking you to use pbzip. bzip at best utilizes one core, both for packing and unpacking. pbzip uses as many cores as IO bandwith allows - with standard SATA SSDs that’s typically around 30.
pbzip can only utilize multiple cores if the archive was created with it as well.
Does something similar happen using
xz?I’ve searched for it and xz also doesn’t use multithreading by default, you can change the program tar uses to compress by passing the
-Ioption. For xz using all possible CPU threads:tar -cv -I 'xz -6 -T0' -f archive.tar.xz [list of directories]The number indicates the compression ratio, the higher the number, the more compressed the archive will be but it will cost more in terms of memory and processing time
Thanks for answering your own question, this is useful information.
There’s nothing technically wrong with using xjf rather than xzf, but it’ll bite you if you ever use a non-linux platform as it’s a GNU extension. I’m not even sure busybox tar supports it.
Damn, I’m using the “tape archiver” (this is what tar means) since I installed HPUX8 in the 90s, from tape, yes…
No no it’s this:
-
Decide you’ve gotta use tar.
-
man tar -
Guess-and-check the flags until it seems to work.
-
Immediately forget the flags.
That was my case until I discovered that GNU tar has got a pretty decent online manual - it’s way better written than the manpage. I rarely forget the options nowadays even though I dont’ use
tarthat frequently.As much as I also do step 4, to be honest I don’t see people use
mananywhere near as much as they should. Whenever faced with the question “what are the arguments for doing xyz”, I immediatelymanit and just tell them - Practically everywhere you can execute a given command, you can also read full and comprehensive documentation, just look!
-
So a serious question from someone who can’t remember console commands ever despite using them constantly.
Why are so many linux CLI commands set up with defaults that no one ever uses? Like if you pretty much always need
-f,-vis often used, and--auto-compressis needed to recognize type by extension. Why aren’t those the defaults to just usingtar?A lot of applications I find are like this too, they don’t come with defaults that work or that anyone would ever use.
One reason to keep in mind is backwards compatibility and the expectancy that every Linux system has the same basic tools that work the same.
Imagine you have a script running on your server that uses a command with or without specific arguments. If the command (say
tar) changes its default parameters this could lead to a lot of nasty side effects from crashes to lost or mangled data. Besides the headache of debugging that, even if you knew about the change beforehand it’s still a lot effort to track down every piece of code that makes use of that command and rewrite it.That’s why programs and interfaces usually add new options over time but are mostly hesitant to remove old ones. And if they do they’ll usually warn the others beforehand that a feature will deprecate while allowing for a transitional period.
One way to solve this conundrum is to simply introduce new commands that offer new features and a more streamlined approach that can replace the older ones in time. Yet a distribution can still ship the older ones alongside the newer ones just in case they are needed.
Looking at pagers (programs that break up long streams of text into multiple pages that you can read one at a time) as a simple example you’ll find that
moreis an older pager program while the newerlessoffers an even better experience (“less is more”, ¿get the joke?). Both come pre-installed as core tools on many distributions. Finally an even more modern alternative ismost, another pager with even better functionality, but you’ll need to install that one yourself.That makes sense!
i leave off the dash ;)
I just use atool (archive tool) instead. It works the same for any common compression format (tar, gzip, zip, 7zip, rar, etc) and comes with handy aliases like
apackandaunpackobsoleting the need to memorize options.There’s ouch too.
ouch stands for Obvious Unified Compression Helper.
great name
Ouch doesn’t do 7z though
It seems like it supports LZMA files which I believe is what 7z files are?
Lzma is a compression algorithm, not (just) a file format
.7z files support lzma compression, but do not use it exclusively
Man page for dummies. Nice! I like it!
That would be
tldrI like this summary much more, it’s a great visual explanation and doesn’t clutter the poor dummy’s mind with ALL the info
tarhas to offer.
I would also recommend -v for verbose and -z when compressing for gzip
What does --auto-compress do?
Auto compress will use gzip if the file ends with .gz, bzip if it ends with .bz, and so on without mentioning -z
OMG always assumed that -c always stands for “compress” and I always placed .gz at the end to remember to place -x when extracting
just now realizing that .tar files aren’t compressed by default, and that that’s the reason why it’s always .tar.gz
tar was originally was for tape archiving so it’s just a stream of headers and files which end up directed to a file or a device. It’s not well ordered, just whatever file happens to be found next is the next in the stream. When you compress the tar this stream it’s just piped through gzip or bzip2 on its way.
The tradeoff for compressing this way is if you want to list the contents of the tar then you essentially have to decompress and stream through the whole thing to see what’s in it unlike a .zip or .7z where there would be a separate index at the end which can be read far more easily.
Took me a while to
I just have
packandextractfunctions in my shell RC files that look at file extensions and use the proper tool with proper arguments.Wrote them 10 years ago and they’ve worked flawlessly ever since!
Brilliant! As an apple engineer, I think I will do the same thing with image previews in iMessage! What can go wrong?
Who could have guessed that an ancient and forgotten image format suddenly gets that big of a revival.
I personally just use
tldrto figure out how it’s done.
