What's the one Linux command you wish you knew years ago?

Note that the + may not be portable. I know it doesn't work on older Solaris versions (<10) and HP-UX (from a couple years ago when I last touched it).

Also, find may or may not split the files it finds into multiple invocations.

Too many invocations of "cat"

find . -name \*.java -print0 | xargs -0 cat | wc -l

Edit: Dammit. Others have already posted this exact version further below. :-(

yes and do you know about proxycommand ?

let you set up hops when you don't have direct access to a server.

e.g. if you don't have direct access to serverB but have direct access to a serverA that has direct access to serverB

put this in your ~/.ssh/config file

  host serverA
  hostname serverA.domainname.com

  host serverB
  hostname serverB.domainname.com
  ProxyCommand ssh serverA "nc %h %p"

then typing ssh serverB will log you on serverB

By reducing the needless complexity that it implements. The purpose of a Unix shell is to interpret a simple language wrapping syscalls so the user can easily give instructions to the kernel. There are several such shells whose source code is smaller than the bash manpage.

13 pages of the 80 page manual are devoted to readline and programmable completion. Readline and programmable completion could be removed from the shell, and their functional equivalents moved to a more logical place in the terminal emulator. Plan 9 does this, and it works well, and people seem to like it and the flexibility it gives.

24 pages are devoted to builtin commands, many of which are unnecessary duplicates of regular commands, and several unnecessary altogether.

3 pages are about weird parameter expansions, all of which can be done more intuitively with sed, except for the array one, which can be done with awk.

And there are many smaller things as well, like biffing or arithmetic evaluation, which can be done with dc or whatever. You could try moving history out of the shell and into the terminal emulator as well.

While it doesn't fix the issue, zsh's man page is divided into different sections, which at least alleviates it.

I wish there was an easy way to get info about builtin commands. So things like man bash-disown would work (similar to git).

Yep, a short list of useful one-liners would go a long way. Often, your use-case will be a straight specialisation of one of the examples, and if not, chances are you can cobble together something from several examples. I'd like to have a auxiliary help command for this, e.g. example ffmpeg in addition to man ffmpeg (another 18k words manpage).

Edit: This works rather well:

  function cmdfu() {
         curl "http://www.commandlinefu.com/commands/matching/$@/$(echo -n $@ | openssl base64)/plaintext" --silent | sed "s/\(^#.*\)/\x1b[32m\1\x1b[0m/g"
  }

From http://www.commandlinefu.com/commands/view/3086/search-comma..., it uses the commandlinefu API: http://www.commandlinefu.com/site/api

yes, bring back the VAX/VMS help system with the helpful examples at the end, was awesome last time I used it.

Same here, most man pages seem pretty good at documenting all the available options, but are pretty useless at explaining how the tool should actually be used.

I'd like to see someone dump all the common man pages into a public wiki so people could flesh out the usage examples and suggest alternative tools.

There is a standard "EXAMPLES" section to manpages. It's just not used often enough.

Most Linux distros have a bug reporting feature which could be used to suggest such examples, and it would be a Good Thing if more were suggested.

You could try the OpenBSD man pages. One of OpenBSD's must-haves is good documentation. If I'm looking for an example and the Linux man doesn't have one, I'll often google for "openbsd man xxxx".

Of course, watch out for differences in the utility. OpenBSD (usually) won't have any GNU extensions, for example.

On my system, the info documentation for bash 3.1, not including indices, is 53610 words, or 105 pages. The content is identical to that in the manpage. In addition, you have to read it in a clunky, unintuitive, and un-Unixy browser. Far from short and to-the-point, I nearly lost interest just trying to figure out how to coax info to send its output to stdout so I could pipe the 105 page book to wc. The info documentation is not in any way I can measure better than the manpage. Both the info documentation (and I use that term loosely) and the manpage are more noise than signal.

Or, for another alternative, w3mman, which is bundled with the w3m browser. Tabbed manpage browsing in the terminal with URLs converted into links and "foo(1)" converted into a link to the man page for "foo". Don't leave home without it.

On the MacBooks I've seen, Page Up/Down is usually Fn+Up Arrow/Fn+Down Arrow. I don't know if this is implemented in software or hardware, though, so if you're running *nix, you might be out of luck.

f and b will do page scrolling in the man viewer.

> The first thing the sys-admin who helped me said was, "type 'man'."

And that also happened. It used to be virtually impossible to jump in alone, because someone had to create an account for you. It's now possible to start in Unix with no one's help. As long as you can figure out how to burn an iso to CD, you're in. The installation gives you an account, with sudo.

After you install CrunchBang, it pops up a terminal the first time you log in, and allows you to make additional choices that weren't made during install.

I think all distros should pop up a terminal upon first boot and direct you to read "man man."

I code in Perl at my day job, and I still use awk and grep. Sometimes it's quicker to do it in awk than perl, especially when you're doing it in command line and have to figure out quotes.

awk -F, '{print $3}' foo | xargs -I{} echo 'command -x -y -z {}'

perl -e 'open F, "<foo"; while(<F>) { my($a,$b,$c,@rest) =split /,/; system("command -x -y -z $c"); }'

I think I could do the split into an array and then take the third element, but I'm just trying to do an elementary example. When you want to do more things to this argument you necessarily have to grow this, and at one point I got to the point where I started having to escape quotes. That's rather difficult to read when you're just trying to do something quick in the command line and you mismatch a pair.

awk (and to a lesser extent sed) is cleaner and easier to remember.

sponge(1) from "moreutils"

Although sort(1) handles this for you as you mention, the general problem in the shell of wanting to overwrite your input file with the output file, but not being able to redirect to it for the reason you mention, is solved with sponge. Rather than:

$ grep "foo" bar.txt >baz.txt; mv baz.txt bar.txt

instead:

$ grep "foo" bar.txt | sponge bar.txt

Thanks for letting me know. It's still probably easier to use the Wayback Machine since all of the site's internal links point to http://sial.org/ so browsing within the site is very painful. Still, I'm glad to see the content is all still online. I may just mirror the whole thing (there's tons of good reference material in there, especially for Perl, but also for Unix generally).