Live data from Hacker News

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

reddit.com

61–70 of 216 posts

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

#62
Quitting SSH connections that hang: ~.

If you frequently connect through VPNs to other hosts, often enough the SSH connection times out and just siits there, taking no commands. Hitting ~ and . will kill the session (it's an openssh feature).

Other frequently used tools: awk, sort, uniq, tail, find, grep.. they alone make the shell a really powerful tool

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

#63
It's not a command but it is still useful. When you are typing a long command and you realize that you need to do other command or set of commands first, usually you type ctrl + c to cancel it. By default it does not save in the history. If you put # (comment the command) in front of the command (you can do it quickly with Ctrl + a #) and then you can use Ctrl + r to get it back. I'm sure there are other ways to save the command in the history but it is a simple way to have the same effect.

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

#64
post #8
post #6

Earlier quoted context omitted.

Never thought to use ``. I always used xargs: find . -name *.java | xargs cat | wc -l

Your approach works better than backtick expansion, since it won't run into 'command line too long' issues; but it will still break on "weird" file names (e.g., file names with spaces in them). The correct way to do this is find . -name *.java -print0 | xargs -0 cat | wc -l

xargs can still run you into the 'too many args' issue. You'll want to use this:

       --max-args=max-args
       -n max-args
              Use  at  most max-args arguments per command
              line.  Fewer than max-args arguments will be used
              if the size (see the -s option) is exceeded,
              unless the -x option is given, in which case xargs
              will exit.

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

#65
post #52
post #24

That reddit thread is delightful, because it is full of wonderful commands that I didn't know, or rarely use, or had forgotten. But it's also terrifying, because it exposes how many people will post questions before using man.

Many comments seem to be shell- and bash-related. Perhaps the thread exposes how difficult to read the bash manpage is. On my system, the bash 4.1 manpage is 41026 words long, or about 80 pages. Manpages are most useful to me when they are short and to-the-point so I can find what I am looking for before I lose interest in skimming through an 80 page book.

How would you make the bash manpage short and to the point, considering the complexity that it implements?

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

#66
post #48

Nobody knows this: the bash extension $ diff -u Internally, bash creates a pipe and passes /dev/fd/XXX to the main command.

Just diff the two directories. $ ls a b a: 1 2 3 4 b: 1 2 3 # Yours: $ diff -u Maybe I'm missing something?

The OP's example is diffing listings of the two directories whereas your command is asking diff to directly work on the directories themselves.

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

#67
post #46

Not really a command but this: mv /path/to/some/file.{jpg,png} Has been a huge timesaver. It's the same as mv /path/to/some/file.jpg /path/to/some/file.png But saves you the typing/copy pasting the path for the second argument. Can also be used with cp etc.

Either that or

    rename jpg png /path/to/some/file.jpg

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

#70
post #65
post #52

Earlier quoted context omitted.

Many comments seem to be shell- and bash-related. Perhaps the thread exposes how difficult to read the bash manpage is. On my system, the bash 4.1 manpage is 41026 words long, or about 80 pages. Manpages are most useful to me when they are short and to-the-point so I can find what I am looking for before I lose interest in skimming through an 80 page book.

How would you make the bash manpage short and to the point, considering the complexity that it implements?

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.

Post reply on HN