Live data from Hacker News

Unix tricks

mmb.pcb.ub.es

221–230 of 232 posts

Re: Unix tricks

#221
post #171

Related earlier discussions: https://news.ycombinator.com/item?id=5022457 https://news.ycombinator.com/item?id=4481234 A pretty good thread on Reddit: http://www.reddit.com/r/linux/comments/mi80x/give_me_that_on... Edit: see https://news.ycombinator.com/item?id=3257393 for a discussion of the above thread. While we're at it, consider using weborf [1] as an alternative to Python's SimpleHTTPServer for simple file shar…

RE: weborf I will have to look at weborf. I have always wished debian packaged publicfile, similar to djbdns or even dbndns. As it is I am still looking for a "djbdns-like http server" that is apt-get installable and actively maintained. I will never understand why gnome-user-share depends on apache...

Consider webfs too. It is even simpler than weborf.

http://packages.debian.org/search?keywords=webfs

Re: Unix tricks

#222

"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…

s/wq/x/g

Duly noted. :)

Re: Unix tricks

#224
Personally I put the following in my .bashrc:

    function pushcd {
        if [ $# -eq 0 ]; then
            pushd ~ > /dev/null
        else
            pushd "$@" > /dev/null
        fi
    }

    alias cd='pushcd'
    alias b='popd > /dev/null'
Then cd saves the history of visited directories and b navigates backwards, e.g.:

    ~$ cd /tmp
    /tmp$ cd /usr
    /usr$ b
    /tmp$ b
    ~$

Re: Unix tricks

#226

Earlier quoted context omitted.

Thanks for the suggestion. I used to have a very customized .bashrc with nice little things like that, but have decided to stick with standard stuff for things that work off of muscle memory. I got tired of sshing into a new box and half the things I'd type wouldn't work properly until I remembered to copy my settings files over, which seemed more trouble than it was worth for a short-lived s3 instance. That's why I…

> I got tired of sshing into a new box ... I've got a public repo of my dotfiles, so the first thing I typically do is "git clone git@github.com:pavellishin/dotfiles.git && cd dotfiles && ./install.sh" After that, I launch tmux, and it's all hunky dory.

Heh.. right after I posted that comment, my thought was: 'you know - the correct answer here would have been to make an Uber command that would suck all the configs in and install them'.

Thanks for giving me the push to do so. I think I'll take your suggestion but put the command on a site somewhere so I can simply 'curl https://foo.bar/configs | bash'

Re: Unix tricks

#227
post #128
post #125

Earlier quoted context omitted.

Alt + . – use the last word of the previous command. $ cp file.txt /some/annoyingly/deep/target/directory/other.txt $ cd then press Alt + . $ pwd # => /some/annoyingly/deep/target/directory

No, that gives the last word, as you say, we want the dirname of the last word. $ echo foo/bar foo/bar $ echo !$ !$:h foo/bar foo

So you say cd M-. M-backspace M-backspace instead of cd M-.. Four keystrokes is still an improvement over shift-1 shift-4 shift-; h, which is five, plus you get to see where you're going to go before you get there.

Re: Unix tricks

#228

Earlier quoted context omitted.

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

No, this is not a bad implementation of a bloom filter, and the size of the minuscule chance matters; unless SHA-256 has a flaw in it that we don't know about, SHA-256 collisions are far less likely than undetected hardware errors in your computer. The universe contains roughly 2²⁶⁵ protons, 500 protons per distinct SHA-256 value, and has existed for roughly 2⁵⁸ seconds, which means there are roughly 2¹⁹⁸ SHA-256 values per second of the age of the universe.

Typical undetected bit error rates on hard disks are one error per 10¹⁴ bits, which is about 2⁴⁷. If your lines are about 64 characters long, you'll have an undetected bit error roughly every 2^(47-6-3) = 2³⁸ lines. SHA-256 will give you an undetected hash collision roughly every 2²⁵⁵ lines. That is, for every 2²¹⁷ disk errors, SHA-256 will introduce an additional error. If you're hashing a billion lines a second (2³⁰) then that will be 2^(217-30) = 2¹⁸⁷ seconds, while the disk is giving you an undetected bit error every minute or so. A year is about 2²⁵ seconds, so that's about 2¹⁶² years, about 10⁴⁹. By comparison, stars will cease to form in about 10¹⁴ years, all planets will be flung from their orbits around the burned-out remnants of stars by random gravitational perturbations in about 10¹⁵ years, the stellar remnants will cease to form cold, dark galaxies in about 10²⁰ years, and all protons will have decayed in about 10⁴⁰ years.

And if you somehow manage to keep running uniq on your very large file at a billion lines a second, in a mere 500 times the amount of time from the universe's birth to the time when nothing is left of matter but black holes, SHA-256 will have produced your first random false collision.

Re: Unix tricks

#229
post #227
post #128

Earlier quoted context omitted.

No, that gives the last word, as you say, we want the dirname of the last word. $ echo foo/bar foo/bar $ echo !$ !$:h foo/bar foo

So you say cd M-. M-backspace M-backspace instead of cd M-.. Four keystrokes is still an improvement over shift-1 shift-4 shift-; h, which is five, plus you get to see where you're going to go before you get there.

You're incorrect. The number of M-backspace you appear to need would seem to depend on how many `little' words comprise the part that needs deleting, e.g. foo/2013-03-13 needed three M-backspace to rid me of the date and a further backspace to remove the trailing slash, which isn't insignificant to all commands, e.g. ls -ld bar/ when bar is a symlink.

In comparison. !$:h understands its task at a higher level. And thanks to key rollover, typing different characters, like !$:h, is quicker than tapping away at . until visual feedback, which may lag, tells me I've done enough.

Re: Unix tricks

#230
post #229
post #227

Earlier quoted context omitted.

So you say cd M-. M-backspace M-backspace instead of cd M-.. Four keystrokes is still an improvement over shift-1 shift-4 shift-; h, which is five, plus you get to see where you're going to go before you get there.

You're incorrect. The number of M-backspace you appear to need would seem to depend on how many `little' words comprise the part that needs deleting, e.g. foo/2013-03-13 needed three M-backspace to rid me of the date and a further backspace to remove the trailing slash, which isn't insignificant to all commands, e.g. ls -ld bar/ when bar is a symlink. In comparison. !$:h understands its task at a higher level. And th…

It's true that M-backspace is occasionally less convenient, but it's usually more convenient.
Post reply on HN