ralph

A ternary op, Python's is nice, would be welcome. ;-)

    map[bool]int{false: 3, true: 14}[foo != 0]

Agreed, Rob Pike, in his search engine example at Google's I/O 2012 IIRC, made the explicit point that mutexes are there and that channels are for joining large concurrent parts of the program together; guarding a data structure seems too small even though it's a common (toy?) example. http://www.youtube.com/watch?feature=player_embedded&v=f...

I realise the point is to show sometimes vim is inappropriate. However, the commands given in the first one are long-winded and not equivalent, I'm not sure the readers who stand to gain from the article will notice this. As I wrote elsewhere...

Having done :v/tcp/d there's no need to match again with :g/tcp/s... since :%s... will do, besides :g//s... would have done. Also, :g/tcp/s/\S\+\s\+\(\S\+\)\s.*/\1/ mandates a whitespace after the second word so it's not equivalent to the given :%!awk '/tcp/ {print $2}'.

Further to my reply to sibling-reply finnw, here's the pattern of digits, further showing his 10 * 9, etc., breakdown.

    $ pins |
    > sed -r '
    >     :a; s/^([0-9])(.*)\1/\1\2a/; ta; s/[0-9]/a/
    >     :b; s/a([0-9])(.*)\1/a\1\2b/; tb; s/[0-9]/b/
    >     s/([0-9])\1/cc/; s/[0-9]/c/
    >     s/[0-9]/d/
    > ' |
    > sort | uniq -c | sort -n
         10 aaaa
         90 aaab
         90 aaba
         90 aabb
         90 abaa
         90 abab
         90 abba
         90 abbb
        720 aabc
        720 abac
        720 abbc
        720 abca
        720 abcb
        720 abcc
       5040 abcd
    $

Right, and about a quarter contain the same digit at least twice in a row, which may be the "double digit" the grandparent referred to.

    $ pins() { seq -f '%04.0f' 0 9999; }
    $ pins | egrep -c '(.)\1'
    2710
    $ pins | egrep -c '(.).*\1'
    4960
    $

How good is the platform detection accuracy? I ask because for goo.gl I see analytics with the + suffix plump for many "Other Unix" when the majority of those would have been Linux.

If definitely existed before 1996 as I recall introducing it to a particular company's servers. :-)

Disappointed to see no mention of GNU Stow there, very handy for /usr/local having multiple version of foo installed and being able to make one of them current, e.g. rewind if a new one breaks things. http://www.gnu.org/software/stow/

It's read as "cmd, stdout to file, stderr to the same place as stdout".

zsh had the idea first IIRC.

No, I meant the window's furniture so no colours. I agree, a tty-wrapper, like tmux, would provide another option.  I don't suppose there are terminals generally about where `tput hs' is true. Have you considered using the end of the prompt line for status, returning to the left for the "$ ", and being happy to do readline's redraw-current-line if you don't like the overwrite should you reach that far?

I too prefer just PS1='$ ', I want the cursor to be the same distance from the margin every time, to have maximum length for typing without wrapping, and the ability to put in a few separator lines between command output by just tapping Return.

However, for your problem, have you considered the terminal's title instead of the top line of the tty? printf '\033]0;foo\007'

Nice to see tr getting some use, though given the sed on either side I wonder if

    sed -r 's/\<./\U&/g; s/ +//g; s/[^a-zA-Z].*//'

would be better. Note, the last s/// doesn't need a g.

Thanks, I think you've corrected me on this before and I haven't learned! My Plan 9 comes from before this switch.

To withdraw shell programming from Unix takes away one of its strengths. Not everything warrants Python, etc.

Fortunately they fixed that errant man page. :-) http://man.cat-v.org/plan_9/1/cat

Removing files is a common need coupled with find yet many readers don't know of -delete; I was pointing it out. That doesn't weaken xargs's valid uses. You seem a little defensive? :-)

What's wrong with

    cat -- * >../foo

given that cat(1posix) does support --.

Backticks, ``, and $(), use IFS to parse the command's output into words which then become the $()'s replacement and IFS normally contains \n.

You wouldn't like Plan 9 then; it wisely took the decision to forbid spaces (U+20) in file names at the kernel level.

I think I'm missing your point. doc[12] aren't changed.

It's most definitely catenate. I understand catenate to mean chain and concatenate to be to chain together. Since "cat foo bar xyzzy" doesn't modify the files to join them in any way I don't think they're chained together.

Besides, ken & Co. aren't daft. con would be short for concatenate. :-)

The difference between

    cat file | foo
    foo <file

assuming foo only reads stdin so `foo file' isn't possible, is that with the latter the shell will open file for reading on file descriptor 0 (stdin) before execing foo and the only cost is the read(2)s that foo does directly from file.

With the needless cat we have cat having to read the bytes and then write(2) them whereupon foo reads them as before. So the number of system calls goes from R to R+W+R assuming all reads and writes use the same block size and more byte copying may be required.

But why run so many greps? I don't think there's a need for -n1 here.

    xargs -rd'\n' grep -l "$@"

With < on a FIFO it's the shell that blocks on opening before the command, e.g. cat, is run.

No, cat(1) stands for catenate, not concatenate. http://en.wiktionary.org/wiki/catenate

Wanting to remove the files was so common that some finds have it built-in. Avoids even the overhead of -exec rm {} +.

    find -name '*.log' -delete

IFS needs some care and attention and read should have -r.

    $ ls -Q
    "   spaces   "
    $ ls | while IFS="\n" read -r f; do ls "$f"; done
       spaces   
    $

For lots of grim detail see David A. Wheeler's http://www.dwheeler.com/essays/fixing-unix-linux-filenames.h...

Sorry, what do you think

    vim $(grep -lr foo | xargs)

is doing? Assuming a missing directory after the `foo' why can't it just be

    vim $(grep -lr foo .)

I don't see that xargs's default behaviour is adding anything.

For

    find . -name foo_fn exec sed -i s/foo_fn/bar_fn/g '{}' \;

you may find -exec's + of use. The above has the fork/execve overhead for each file found.

    find -name '*.[ch]' -exec sed -i 's/\<foo\>/bar/g' {} +

I too like xargs but see no need for these two xargs given sed is already used?

    find images -name '*.jpg' |
    sed 's/\.jpg$//
        s/.*/convert -geometry 200x &.jpg &_thumb.jpg/'