Those are straightforward; it's the remaining 900 options that are confusing. I always need to look up --excludes and always get --directory wrong, somehow.
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
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 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.)
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.
Yes, 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.
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 -I option. 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
Why when explaining, giving examples of shell command are people so often providing shortened arguments. It makes it all seam like some random letters you have to remeber by heart. Instead of -x just write --extract. If in the end they endup using the tool so often they need to write it fast they'll check the shortcuts.
tar -xf is not really special combining short options isn't uncommon.
Where tar is nonstandard is that you can leave out the -, tar xf is actually how POSIX specifies it. And we've kinda come full circle on that one with many modern utilities using a command syntax, you can read tar xf as "tar extract file" just as you can read git pull as, well, "git pull".
If you want to see a standard command with truly non-standard syntax have a look at dd.
Many do as it's considered good practice, but it's not guaranteed, it just depends on the individual command (program). Usually you can use the --help option to see all the options, so for instance tar --help.
Most commands will have expanded arguments started with 2 dashes that usually look like '--verbose-name-of-option', they're usually listed in the man page/documentation along with the abbreviated letter version
They are random letters you have to learn by hard. No one uses the long form. If someone just needs to use it one time they will copy the line from somewhere.
I don't think tar is actually hard, we are just in the time where we externalize more information into resources such as Google. Its the same reason why younger people don't remember routes by name or cardinal direction as much anymore.
side note: $ tldr is much better than man for just getting common stuff done.
They are functionally flags though and uniletter flags should be preceded by a '-', so I would still prefer to have the '-' written, because it conforms with the standard.
I have to Google for this everytime. What I can never remember is how to check whether I should put my tar.gz into the subfolder first or risk getting a thousand files sprayed into my homedir.
I know the basics off by heart. Not the hardest command syntax to learn all things considered.
The most annoying would be the growing collection of "uber commands" which are much more of a pain in the ass - aws, systemctl, docker, kubectl, npm, cargo, etc. - the executable has potentially dozens of subcommands, each of which has dozens of parameters.
Powershell is horrible all right. What annoys me is they alias ls, dir and other common commands onto commands which don't act or behave in the same way at all. I just run bash or command prompt rather than deal with the bs of powershell.
I'm sorry, I was trying to be silly and poke fun at how most of us just use the one or two tar commands and it totally didn't translate in text like it did my head. Have a wonderful day good internet stranger.
Saved this. Just like I did for tens of tar cheat sheets before. No, I won't remember it exists when I'll need to use tar. I will google it. I'll read that Stack Overflow page again. I will not enjoy it.
Nowaday I have ChatGPT spew me command. I usually do a quick validation before running. Nevertheless, most of simple operations are correct so I don't need to.
I then note the command to my persional gist cheatsheet. Next time, since the command is "cached", I'll be able to be productive quicker.
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, -v is often used, and --auto-compress is needed to recognize type by extension. Why aren't those the defaults to just using tar?
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 more is an older pager program while the newer less offers 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 is most, another pager with even better functionality, but you'll need to install that one yourself.
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 apack and aunpack obsoleting the need to memorize options.
I've been using only xf for a long time now. Don't remember ever getting an error from it in the last years. Maybe tar can now check the magic number or something to figure out what the format is?
tar cf foo.tar.xz wherever/
zip -r foo.zip wherever/
7z a foo.7z wherever/
I get that tar needs an f for no-longer-relevant reasons whereas other tools don't, but I never understood the meme about it beyond that.
Is c for "create" really that much worse than a for "add"?
7z x to extract makes sense. unzip even more. No need for crazy mnemonics or colorful explanation images. It's complete nonsense that people are ok with that.
If you want to do more than just "pack this directory up just as it is" you'll pretty quickly get to the limits of zip. tar is way more flexible about selecting partial contents and transformation on packing or extraction.
100% of tarballs that I had to deal with were instances of "pack this directory up just as it is" because it is usually people distributing source code who insist on using tarballs.
Yes, and I'd rather not have my time wasted by waiting on thousands of small files transfer, rather than just compressing it and the time spent of one file transferring being much smaller.
I think that's pretty mean towards the free software developers spending their spare time on Latex and the GNU utils.
I and many academics use Latex, and I personally am very happy to be able to use something which is plain text and FLOSS.
I also don't see your problems with tar; it does one thing and it does it good enough.
I also don’t see your problems with tar; it does one thing and it does it good enough.
The problem is the usage of the tool which people invent different mnemonics for because it's UX is stuck in 1986 and the only people who remember the parameters are those who use it daily.
Similar thing for LaTeX: it's so absurdly crusty and painful to work with it's only used by people who have no alternative.
//ETA
Also, I don't want to be mean towards the maintainers of LaTeX. I'm sorry if I made any LaTeX maintainer reading this upset or feel inferior. Working on the LaTeX code is surely no easy endeavour and people who still do that in 2023 deserve a good amount of respect.
But everytime I had to work with LaTeX or any of its wrappers was just pure frustration at the usage and the whole project. The absolute chaos of different distributions, templates, classes and whatnot is something I never want to experience again.
Thanks I'll keep an eye on that project. I did try pandoc and LyX in the past to ease the pain but typst appears to have the courage to finally let LaTeX be and not build a new wrapper around it.
tar --helpcross fingers
tar --hep
Fuck.
Here, this should help.
It should be a crime to directly link XKCDs images without the corresponding page.
https://xkcd.com/1168/
I understand and sympathize with Rob on a spiritual level.
I remember it like this:
tar -extract ze file
and
tar -compress ze file
And also tar -the fuck is in this file
z is for gz files only though, there are plenty of others. xf autodetects and works with all of them (with GNU tar att least).
Same. This pic has been helpfully living in my memory for probably a decade.
I hope whoever thought
-lshould mean "check links" instead of list has a special place in Hell set aside for them.I have no idea what
print a message if not all links are dumpedeven means.Was gonna say this. Why TF is list not -l as...everywhere else?
Xtract Ze Vucking File!
I always did Xtract Ze File but I will add Vucking from now on, thanks!
Ah yes, that's the linux community as I know it. There is one thing someone wants to achieve and dozens of ways to do it. ;)
Nah I just use 7z
Those are straightforward; it's the remaining 900 options that are confusing. I always need to look up
--excludes and always get--directorywrong, somehow.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
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.
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.
I got toxoplasmosis that way
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 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 shortcutThere'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.
Yes, 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.
Why when explaining, giving examples of shell command are people so often providing shortened arguments. It makes it all seam like some random letters you have to remeber by heart. Instead of -x just write --extract. If in the end they endup using the tool so often they need to write it fast they'll check the shortcuts.
Does every Linux command have options as words instead of single letters?
Tar is as old as IT, that's why it's syntax is a bit special.
tar -xfis not really special combining short options isn't uncommon.Where tar is nonstandard is that you can leave out the
-,tar xfis actually how POSIX specifies it. And we've kinda come full circle on that one with many modern utilities using a command syntax, you can readtar xfas "tar extract file" just as you can readgit pullas, well, "git pull".If you want to see a standard command with truly non-standard syntax have a look at
dd.Nono, dash-parameters are new in fancy GNU tar. And POSIX is not old.
Many do as it's considered good practice, but it's not guaranteed, it just depends on the individual command (program). Usually you can use the
--helpoption to see all the options, so for instancetar --help.Most commands will have expanded arguments started with 2 dashes that usually look like '--verbose-name-of-option', they're usually listed in the man page/documentation along with the abbreviated letter version
They are random letters you have to learn by hard. No one uses the long form. If someone just needs to use it one time they will copy the line from somewhere.
Or just use long-forms like
instead of
or
tar -xf pics.tar
I don't think tar is actually hard, we are just in the time where we externalize more information into resources such as Google. Its the same reason why younger people don't remember routes by name or cardinal direction as much anymore.
side note: $ tldr is much better than man for just getting common stuff done.
Yes, but still tar options are kinda janky.
The “-“ is often not necessary. I use it as a guide to see how long the person running tar has been using it.
Example:
tar -xf file.tar == tar xf file.tar
They are functionally flags though and uniletter flags should be preceded by a '-', so I would still prefer to have the '-' written, because it conforms with the standard.
But muh POSIX
yeah, you can also ditch that f
tar c /etc/passwd > fu.tar
tar t < fu.tar
tar x < fu.tar
I have to Google for this everytime. What I can never remember is how to check whether I should put my tar.gz into the subfolder first or risk getting a thousand files sprayed into my homedir.
If you have a somewhat decent shell, just smack tab twice after the filename, it'll list the directories present.
I know the basics off by heart. Not the hardest command syntax to learn all things considered.
The most annoying would be the growing collection of "uber commands" which are much more of a pain in the ass - aws, systemctl, docker, kubectl, npm, cargo, etc. - the executable has potentially dozens of subcommands, each of which has dozens of parameters.
These "uber commands" tend to be much better since they are more explorable with
--helpexplanations and readable flags.Much better than the random jumble of characters you're expected to have memorised for awk, sed, find et al.
PowerShell is so much worse.
Powershell is horrible all right. What annoys me is they alias ls, dir and other common commands onto commands which don't act or behave in the same way at all. I just run bash or command prompt rather than deal with the bs of powershell.
I very much disagree, what are you referring to?
Yes, that's all very well, but you'll still need to find that image the next time you want to use 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.Simple:
tar -(whatever options you want here, my go to is xvzf or cvzf) archive-name.tar file/folder-to-compress
Create ze vuking file
Xtraxt ze vuking file
oh my god, thank you for this
tar can do things other than this?
Oh I'm aware, I'm just saying this is what I normally do with it
I'm sorry, I was trying to be silly and poke fun at how most of us just use the one or two tar commands and it totally didn't translate in text like it did my head. Have a wonderful day good internet stranger.
Just use Ouch!
Thank you, I still don't understand.
I use Linux for years and still Google every time I have to use it!
For me it's because I don't use it very often, mostly just archiving stuff every few months or so.
Yea, I use it from time to time but not very often and the syntax are as unintuitive as it gets (at least to my brain)
dtrx is the way to do it. It's short for "do the right extraction", and it just works.
Also, all you have to remember for tar is "-xtract -zee -vucking -files" (extract the fucking files, but first letters only)
You can drop the awkward one and just -xtract -zee -files without -verbose output
What is "listing"?
lists the files in the archive. So you don't need to extract the entire archive. Useful for huge archives.
Thanks!
As a mnemonic I usually read the "f" as "fucking":
tar,compressfuckingpics.tar.gzwith junk from./picstar, extractfuckingpics.tar.gzThat's only for scripting though. Most of the time I simply right-click the directory or archive, and let Engrampa deal with it.
I usually just use
tar -xvf {file}-- I like the verbosity when extracting just so I know it actually is doing things.Just add -a for auto compression.
Do you know if it recognize tgz extension?
Pretty sure it just reads the file contents, so extension is irrelevant, but either way it definitely works with the
.tgzextension.tar xafvevery time, works like a charm.^r tarand adjust as needed. Got itMy
tarcommand istldr tarthenctrl + c/ctrl + vi leave off the dash ;)
I didn't know about auto-compress, thanks!
Saved this. Just like I did for tens of tar cheat sheets before. No, I won't remember it exists when I'll need to use tar. I will google it. I'll read that Stack Overflow page again. I will not enjoy it.
T_T
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
tar, please eXtract the Vucking File!tar -xvf tarbomb.tar.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'll keep using TLDR, best cli command ever.
Damn, I'm using the "tape archiver" (this is what tar means) since I installed HPUX8 in the 90s, from tape, yes...
That looks really cool. And finally a guide that knows
-zis not necessary all the time.Nowaday I have ChatGPT spew me command. I usually do a quick validation before running. Nevertheless, most of simple operations are correct so I don't need to.
I then note the command to my persional gist cheatsheet. Next time, since the command is "cached", I'll be able to be productive quicker.
So much better than googling.
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!
Or
-I 'compress-command' -cf ...if not supported.I've written a CLI tool in Rust as a front end to tar with gzip called Targez.
It can definitely just be done with an alias instead, but you can give it a try if you prefer something installable.
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.
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
I always use tldr for these things, super handy to have.
You should link TealDeer, which is the same but it's compiled in rust instead of node so it takes less memory, also, the name is cooler :)
You are absolutely right, this is way better. Thanks!
OMG always assumed that -c always stands for "compress" and I always placed .gz at the end to remember to place -x when extracting
Check out atool
Don't you have to specify the compression algorithm when extracting? I always use
tar -xzffor gzip files and if I remove -z it just fails.I've been using only
xffor a long time now. Don't remember ever getting an error from it in the last years. Maybe tar can now check the magic number or something to figure out what the format is?great, now how do I use it together with the 'feather' command?
Do more like this (・へ・)
taris just the worst shell command in existence. Why do people still bother with it?Because it is faster to transport one big ass tar than 10k individual files, and compression is waste of time.
What do you use instead?
atool is a good alternative apparently, but I am still new to it
I use zip/unzip if I have the option
I avoid it and use zip or 7z if I can. But for some crazy reason some people stil insist on using that garbage tool and I have no idea why.
Are zip and 7z really that much easier?
I get that
tarneeds anffor no-longer-relevant reasons whereas other tools don't, but I never understood the meme about it beyond that. Iscfor "create" really that much worse thanafor "add"?7z xto extract makes sense.unzipeven more. No need for crazy mnemonics or colorful explanation images. It's complete nonsense that people are ok with that.If you want to do more than just "pack this directory up just as it is" you'll pretty quickly get to the limits of zip. tar is way more flexible about selecting partial contents and transformation on packing or extraction.
100% of tarballs that I had to deal with were instances of "pack this directory up just as it is" because it is usually people distributing source code who insist on using tarballs.
You do you. Compression is waste of time; storage is cheap in that you can get more, but time? Time, you never get back.
Yes, and I'd rather not have my time wasted by waiting on thousands of small files transfer, rather than just compressing it and the time spent of one file transferring being much smaller.
Tar achieves the same effect without time to compress and decompress.
as in time wasted transferring a highly compressible file that you didn't bother compressing first?
it's only a waste of time when the file format is already compressed.
Unless you measure your baud in dial up modem, it often can take longer to compress / transport / uncompress than just transfer directly.
unless you're picking a slow compressor that's not true at all
Add a zero to your link speed - 10Gbs
Because everyone else does, and if everyone else does, then I must, and if I do, then everyone else must, and then everyone else does.
Repeat loop.
For all I care it goes on the same garbage dump as LaTeX.
I think that's pretty mean towards the free software developers spending their spare time on Latex and the GNU utils.
I and many academics use Latex, and I personally am very happy to be able to use something which is plain text and FLOSS.
I also don't see your problems with tar; it does one thing and it does it good enough.
The problem is the usage of the tool which people invent different mnemonics for because it's UX is stuck in 1986 and the only people who remember the parameters are those who use it daily.
Similar thing for LaTeX: it's so absurdly crusty and painful to work with it's only used by people who have no alternative.
//ETA
Also, I don't want to be mean towards the maintainers of LaTeX. I'm sorry if I made any LaTeX maintainer reading this upset or feel inferior. Working on the LaTeX code is surely no easy endeavour and people who still do that in 2023 deserve a good amount of respect.
But everytime I had to work with LaTeX or any of its wrappers was just pure frustration at the usage and the whole project. The absolute chaos of different distributions, templates, classes and whatnot is something I never want to experience again.
speaking of which, you might want to check out typst if you haven't heard of it - I really hope this replaces most uses of LaTeX in the next years.
Thanks I'll keep an eye on that project. I did try pandoc and LyX in the past to ease the pain but typst appears to have the courage to finally let LaTeX be and not build a new wrapper around it.
You've never used
findhave you? Let's not even get started on the config file syntax forsendmaileither.@anteaters @sebastiancarlos a little knowledge really is a dangerous thing