61–67 of 67 posts
Those are, indeed, 8 commands every developer should know. Calling them "Linux Commands" is a little weird - I don't think there's anything there not specified in POSIX, and I think they all appear on OS X and other unix systems.
Hmmm, is this HN worthy? These commands are so basic that I don't expect any HN-reader using Unix systems not to know those. What about some slightly less basic ones that I'd think would be useful for many people. # less with syntax highlighting alias less="/usr/share/vim/vimcurrent/macros/less.sh" tailf # tail -f, but better & shorter mtr # check your connection (ie., traceroute with more info) htop # nice a colorfu…
If you are going to use vim, why bit he pretending it is less? Just use vim.
I was expecting to see the first comment in here complaining about his use of 'cat', as in all of the examples his second argument could've easily taken a filename argument.. sort order.* is surely more elegant than cat order.* | sort which is fair enough, however, as it happens, i generally do end up using 'cat' in the way he's used it.. for such small jobs nobody can be genuinely worried about the overhead, and it…
If you really prefer to see things in order then is an alternative to cat foo | sort | ... though I wouldn't particularly recommend it. Instead the overhead of cat(1) should be omitted and it written in the normally accepted form of sort foo | ... Providing a filename rather than re-directing stdin allows the program more choice over its method of access.
While iterating on a command line, it keeps things uniform, rather than switching between "sort foo" and "tai64nlocal < foo" and "ffmpeg -i foo", by which I mean: different programs take their input in different ways. You can normalize by making each take standard input, and feed the chain with a "cat".
Earlier quoted context omitted.
If you really prefer to see things in order then is an alternative to cat foo | sort | ... though I wouldn't particularly recommend it. Instead the overhead of cat(1) should be omitted and it written in the normally accepted form of sort foo | ... Providing a filename rather than re-directing stdin allows the program more choice over its method of access.
I find the "cat foo | .." in the beginning and "| cat > bar" at the end form more regular. While iterating on a command line, it keeps things uniform, rather than switching between "sort foo" and "tai64nlocal < foo" and "ffmpeg -i foo", by which I mean: different programs take their input in different ways. You can normalize by making each take standard input, and feed the chain with a "cat".
If sort, tai64nlocal, and ffmpeg are all happy to read stdin so you can do
cat foo | sort ...
cat foo | tai64nlocal ...
cat foo | ffmpeg ...
... | sort | cat >foo
... | sort >foo
One I learned for the first time the other day is 'paste'. Good for people like me who never fully grokked awk, it joins lines from separate files into a single file. Say you have two files, one with lines of numbers: 1 2 3 ... and one with letters: A B C $ paste numbers letters 1 A 2 B 3 C Want CSV? $ paste -d, numbers letters 1,A 2,B 3,C Or, with '-s' you can join lines from inside the same file. For instance, you…
`paste` is also very useful together with stdin redirection and subshells. E.g.: paste
I think it's obligatory that someone writes 'strace' in threads about articles like this, so here goes. strace is fantastic for debugging certain categories of problem.
I'm yet to find a decent introduction to strace (or dtrace). I'd appreciate if someone could point me to one...
https://blogs.oracle.com/ksplice/entry/strace_the_sysadmin_s...
More from a sysadmin POV than a dev, but you'd probably still find it useful.
tail -f filename should definitely make the list, essential for watching what's appended to log files in real time.
less +F filename does the same thing, but loses the following when the logfile gets rotated. Does the same thing happen to tail -f? (edit: alexfoo answered that tail -F tracks the file properly) one benefit to less +F is that you can cancel the following and read normally in less.
Yeah, including doing backwards and forward searches, that is very handy