- TFA says that `ln` is "used to create symbolic links, among other things"; I'd drop "symbolic"--that is needlessly restricting what it does. It just creates filesystem links; hard or soft.
- TFA says, "tar is actually short for TApe aRchive". The "a" should belong to "archive" ("Tape ARchive"); this is because of it's relation to the older `ar` ("ARchive") command.[^1]
- TFA says, "the filename is actually part of the f flag, and therefore must directly follow it." That's actually not the case for the "dash-less" form of tar invocation; all of the flags go in one string, and then the arguments follow in the same order, rather than right after the associated flag. For example, if I wanted to specify both the "f" and "C" flags, it (c|w)ould be something like `tar cfC argument-to-f argument-to-C`. That said, modern tars also support `tar -c -f argument-to-f -C argument-to-C`.
As TFA says, this isn't inherently wrong, it's just different than everything else (I know of no other command that uses that flag syntax[^2]). Understand that it predates the standard convention that everything else follows.
[^1]: Today ar is pretty much only used for creating .a files containing library objects for static linking. It may be noteworthy that the argument order of ar is ALSO "archive-name members..." despite archive-name NOT being an argument to an "-f"-like flag.
[^2]: Actually, come to think of it, `ps` might take that syntax, depending on your system.
usage: ln [-Ffhinsv] source_file [target_file]
ln [-Ffhinsv] source_file ... target_dir
my_link --> real_directory
$ ln real_directory my_link
My brain thinks it breaks the idiom of `[cmd] [from] [to]` that cp, mv, etc use. You wouldn't say the example above is a link from real_dir to my_link, you'd say the opposite (and that's what the cli shows when you ls a link).
Also, in sections 1 and 8 (shell), data typically flows from left-to-right across the line. The filename on the left flows into the link on the right. Data flows from the left of the pipe to the right.
Whereas in section 3 (C), data typically flows from right-to-left across the line. Variable assignment, memcpy, ...
There are of course exceptions (dup2, bcopy), but that's the general style for the order of arguments in *nix.
I have to look up ln every time.
* Description of "ln" is more general
* "Tape ARchive" is now described correctly
* No longer uses the arguments in "dash-less" mode
What is it exactly called?
Do you have any examples of modern utilities using a dash-less syntax?
Ironically, I think it'd actually be more intuitive if we used the options fully; tar -c -f filename -z (list of files). But we end up memorizing shorthand before we know what it means, rather than after.
(Same with find: first time a friend hacker dictated me a find command, next step I read the manual and since then I've been a happy find user).
The secret of unix diffusion has been its man pages, full documentation of your local unix system, specific and always available on-line (even when the network is disconnected).
Nowdays, with google or stackoverflow, you have the big problem that the documentation you get doesn't necessarily (probably never) match your specific installation, when you search for documentation, and that you get more fishes than fishing lessons.
tar was later changed to read/extract(-x) and write/create(-c) from files(-f). And was also modified to handle gzip(-z) and bzip2(-j) compression.
Essentially, the problem comes down to having to support all of the old scripts that depend on default tar behavior, even though people rarely write to tape drives with it any more.
For example, to add/update an entry in a zip file, do:
zip test.zip test/test.txt
ar cr test.a test/test.txt
How did you come to the conclusion about which is most commonly encountered?
Also, other popular archivers also use the archive-first approach:
7z.exe a c:\a.7z file1.txt dir2\file2.txt
rar a -r yourfiles.rar *.txt c:\yourfolder
Even though I've probably run across more .zip files than .tar files (and certainly more archives of in the zip format) in my career, if undoubtedly typed 't-a-r' on a command line many more times than 'z-i-p'.
cp file1.txt file2.txt file3.txt destination/
mv file1.txt file2.txt file3.txt destination/
copy file1.txt file2.txt file3.txt destination\
move file1.txt file2.txt file3.txt destination\
Similarly, the hypothesis predicts that people who use the command-line to work regularly with .jar, .odf, and other zip-based file formats will also have problem with the ordering.
I have not heard of such problems, but I am not knowledgeable about those areas of development.
I tend to use tar -czf <file> to untar. If it didn't work I'd proceed to tar -xzf <file> or tar xzf <file>. Even so sometime my machine wouldn't accept the command until I tried something like untar (not real!) or unzip or gzip. But those were mostly out of frustration.
Recently I've switched to patool (http://wummel.github.io/patool/) and quite happy with it.
I don't see how it's difficult. Are [li|u]nix admins getting more stupid?
How about writing a valid firewalld configuration command to open port 8060 TCP and UDP to connections from 10.0.0.0/8 and have it saved and applied immediately.
I think Veritas and their thousands customers would beg to differ.
"tar cf"? "cf"? There's your problem! If you follow the anachronistic "bundled flags" approach no wonder you're getting it wrong. "tar -c -f <parm>"!
(you don't need anything else)
tar -c files | gzip > ../foo.tgz
No messing around with flags, just a single one saying that you want to create an archive rather than extract one. No messing around with filename parameters—that's what the shell is there for.
(GNU tar can do it all in one command)