Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix tricks

mmb.pcb.ub.es

Post reply on HN
Print view View original

201–210 of 232 posts

Re: Unix tricks

#201

Post by hiroaki »

unfletch wrote: post #70

'!!:n' selects the nth argument of the last command, and '!$' the last arg A lot of people know about "!$" (which is shorthand for !!:$), but that's just the tip of Bash's history expansion. I use these things all the time. One of my favorite keystroke savers is adding :h, the head modifier, to !$. For example: $ cp file.txt /some/annoyingly/deep/target/directory/other.txt $ cd !$:h $ pwd # => /some/annoyingly/deep/t…

  $ !!
runs the previous command.

This is especially useful:

  $ !!
  $ sudo !!

Re: Unix tricks

#202

Post by klibertp »

aw3c2 wrote: post #127
gcv wrote: post #65

Learn to use your shell's globbing features instead of overusing find. In zsh, you can do 'print -l /*.(c|cc|h|hh)' for example (I'm sure bash has an equivalent).

does that work for say 2143789 files?

I actually hit a limit quite a few times already - I don't remember if it was the shell that complained or the command (mv, cp, ...) itself, but I know I couldn't execute the command. find with xargs or -exec worked, however.

Re: Unix tricks

#203

Post by re_todd »

rburhum wrote: post #85

I freaked out when I found out about the "screen" command several years back. "screen" starts a virtual screen that you can detach from with "ctrl-a d" and you can log out, login from a different machine/session and reattach with "screen -r". it has history so you can run long running commands and reattach 3 days later to continue from where you left off as if you had been logged in the whole time.

Tmux is similar, here is a cheat sheet that helped me move from screen to tmux: http://www.dayid.org/os/notes/tm.html

Re: Unix tricks

#204

Post by carlesfe »

nonamegiven wrote: post #197

"Add "set -o vi" in your ~/.bashrc to make use the vi keybindings instead of the Emacs ones." Better to do this kind of thing in .inputrc, as: set editing-mode vi (or set editing-mode emacs) because any application that uses readline gets to use those settings. So for example you get command line editing in various command line apps. bash uses readline, so you'll get that. The python repl will give command line editi…

Oh, wow, you just made my day. I love vim-style line-editing.

Re: Unix tricks

#205

Post by ampersandy »

jevinskie wrote: post #194
crusso wrote: post #20

The special bash command I'm most often asked about by shoulder surfers is !$. It substitutes the last argument in the previous command into the current one. For example: $ ls /some/long/path/somewhere/looking/around/ $ cd !$ cd /some/long/path/somewhere/looking/around/

Is there one for all but the first argument?

!!:2-$

Re: Unix tricks

#206

Post by james2vegas »

nonamegiven wrote: post #197

"Add "set -o vi" in your ~/.bashrc to make use the vi keybindings instead of the Emacs ones." Better to do this kind of thing in .inputrc, as: set editing-mode vi (or set editing-mode emacs) because any application that uses readline gets to use those settings. So for example you get command line editing in various command line apps. bash uses readline, so you'll get that. The python repl will give command line editi…

'set -o vi' is more likely to something that isn't bound up tight with readline, like /bin/sh

Re: Unix tricks

#207

Post by gingerlime »

npsimons wrote: post #84
niggler wrote: post #14

Earlier quoted context omitted.

1. `man pgrep` is your friend (you save two greps, and TBH the `grep -v grep` should be a hint that there's a better way) 2. In my experience on Debian (granted this was in 2010), there is a noticeable performance difference between `htop` and `top`. 4. ssh-agent stores the password in memory and is erased on reboot. OTOH If you use a passwordless key file, anyone can use it if they have the key.

I'm pretty sure ssh-agent doesn't store the password, but the private key. Also, the fact that it supports timed expire (and can be setup to drop keys upon events such as screen lock) make it a wiser choice than passwordless keys.

That's correct. And ssh-agent doesn't give access to the private key either, only to perform operations like signing. The only way to extract the key is to search it in the process memory, which I believe would requires root level access.

Re: Unix tricks

#208

Post by kilburn »

bumbledraven wrote: post #196
alexkus wrote: post #121

Earlier quoted context omitted.

Yes it will, and a bit (read: a lot) more than 10GB as it needs to store the contents of variable x in a hash table (with the corresponding hash key and value of the counter). There's no other magic way it can 'know' whether a particular line has been seen before. You can't rely on hash keys alone as the hashes aren't guaranteed to be unique. For files with relatively few duplicates it's going to be a lot slower than…

Yes it will ... [need] to store the contents of variable x in a hash table [...] There's no other magic way it can 'know' whether a particular line has been seen before. You can't rely on hash keys alone as the hashes aren't guaranteed to be unique. Technically that's true, but the result of a cryptographic hash like SHA-256 is (practically) guaranteed to be unique. Depending on the average length of an input line an…

You are describing a bad implementation of a bloom filter [1]. Anyway, people expect "uniq" to be correct in all cases (i.e., to never filter a unique line). A default implementation where it would possible (even with a minuscule chance) that this doesn't happen would be a recipe for disaster. It may be a cool option though ;)

http://en.wikipedia.org/wiki/Bloom_filter

Re: Unix tricks

#209

Post by aw3c2 »

klibertp wrote: post #202
aw3c2 wrote: post #127

Earlier quoted context omitted.

does that work for say 2143789 files?

I actually hit a limit quite a few times already - I don't remember if it was the shell that complained or the command (mv, cp, ...) itself, but I know I couldn't execute the command. find with xargs or -exec worked, however.

It's what happens if one uses * or similar globbing. The shell will try to pass all the files as arguments to the command and if it is too many, it will fail. That is why using find is often needed.

Re: Unix tricks

#210

Post by garethadams »

crusso wrote: post #80
kps wrote: post #39

Earlier quoted context omitted.

An arguably better (and slightly more portable) way to accomplish this is the special variable $_ , which expands to the last argument of the previous command. Since $_ is a variable rather than a history substitution, it still works when there is no command history (e.g. in scripts) and allows all the usual variable expansion forms, for example ${_##*/} to extract the last path component.

That's good to know, although !$ is easier to type since you only need to depress the right shift key, whereas yours requires a quick shift on the opposite side. Makes a big difference when you're trying to quickly type "rm -rf !$" as root. :)

I don't think I'd type `rm -rf [anything]` quickly as root
Post reply on HN