3 ms·

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() {

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 }

akerl_ 10y ago
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
- tomsmeding 10y ago
  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 :)
  - akerl_ 10y ago
    Have you tried it out? It worked on my system.
    - IsmaOlvey 10y ago
      The parent is correct, the given command redirects stdout to stderr, it's not copied (so stdout will be empty).
      - akerl_ 10y ago
        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 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.
- xelxebar 10y ago
  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
reacweb 10y ago
I would favor "dig en.wikipedia.org +short". I think it is installed by default (ubuntu, redhat). It does not require string parsing.
- reacweb 10y ago
  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.
prakashk 10y ago
Also: resolveip -s $1 | tee >(xsel -b) (which I prefer)

akerl_ 10y ago

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

tomsmeding 10y ago
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 :)
- akerl_ 10y ago
  Have you tried it out? It worked on my system.
  - IsmaOlvey 10y ago
    The parent is correct, the given command redirects stdout to stderr, it's not copied (so stdout will be empty).
    - akerl_ 10y ago
      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 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.
xelxebar 10y ago
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

reacweb 10y ago

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

reacweb 10y ago
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.

prakashk 10y ago

Also: resolveip -s $1 | tee >(xsel -b) (which I prefer)