Hacker News Reader

Comment by z1mm32m4n | Hacker News Reader

What a list of gems!

Also, I noticed you can rewrite this function:

    # Copy an ip address from a domain
    # Usage cip domain.com
    function cip() {
        ip=$(resolveip -s $1)
        echo $ip | xsel -b
        echo $ip
    }

as a oneliner without needing process substitution or echo:

    function cip() {
        resolveip -s $1 | tee /dev/fd/2 | xsel -b
    }

View on HN

I'm never 100% sure I understand FD redirection, but I think you can shorten that even further to:

    function cip() {
        resolveip -s $1 1>&2 | xsel -b
    }

Since this'll copy stdout to stderr, and then stdout will get eaten by xsel

It won't copy stdout to stderr; it'll move stdout to stderr. Stdout will be empty after the redirect, so no, thos won't work :)

Have you tried it out? It worked on my system.

The parent is correct, the given command redirects stdout to stderr, it's not copied (so stdout will be empty).

Again, have you tried it?

    # echo "foo" 1>&2 | sed 's/foo/bar/'
    foo
    bar

Edit: I've done some more testing, and discovered that the above works on zsh, but not in bash

2nd Edit: Ahha! http://www.cs.elte.hu/zsh-manual/zsh_7.html . So this is because zsh w/ the stock config (MULTIOS option enabled) will open as many outputs as you give it. So it can both copy FD 1's contents to FD 2 and to the pipe'd command.

A little spelunking may help:

    $ lsof  -d 0,1,2 -a -p $$

That will show you what files correspond to what file descriptors for your current shell process. You can then experiment with redirects. To see how a pipe works we can do something similar:

    $ sleep 1 | lsof -d 0,1,2 -a -p $(sh -c 'echo $PPID')

Anyway, thinking of `>` and `<` as just FD setters made things a lot clearer for me personally. They just set the file descriptor on the left to file on the right and `&n` can be used to "dereference" a FD to its corresponding file. The only real difference between `>` and `<` is that the former opens the file with write permission while the latter opens it with read. Well, and the default FDs are different.

Incidentally, this makes it clear why the following doesn't work as expected:

    $ curl 'https://kernel.org/' >/dev/null 2>&1 | tee curl.errs

Since FDs get set in the order they are specified, 1 gets set to /dev/null and then 2 gets set to whatever 1 is, i.e /dev/null. So it's clear that we probably intended the following:

    $ curl 'https://kernel.org/' 2>&1 >/dev/null | tee curl.errs

Which lets us ignore stdin and maybe pipe stdout to some other command.

Now I hope Linus doesn't hate on me for abusing kernel.org :P

I would favor "dig en.wikipedia.org +short". I think it is installed by default (ubuntu, redhat). It does not require string parsing.

This article is very interesting, but I prefer to use sed or readlink /proc/<pid>/cwd instead of learning additional commands like rename and pwdx.

Also:

    resolveip -s $1 | tee >(xsel -b)

(which I prefer)

Reply on news.ycombinator.com