ralph

Both the article's improved pipeline and Doug McIlroy's original have a bug. I've just written about it on +Ade Oshineye's post about the original article. https://plus.google.com/105037104815911535953/posts/KuXczyiw...

I agree, annoying, and I didn't realise many others thought the same. Thanks for the link, I've tried to spread the word. https://plus.google.com/115649437518703495227/posts/iWtSJhR8...

See `failglob' elsewhere on this page. What you suggest is sometimes useful but also sometimes wrong and hard to spot because the glob might match locally and one not realise.

Personally, I `shopt -s failglob' in my .bashrc so any glob that fails to expand is treated as an error by the shell and the command never gets started. I then quote all special globbing characters that I intend to pass to the command as it avoids the sometimes hard to spot errors where a glob expanded unintentionally and the command didn't see the wildcards. Relying on non-matching globbing to reach the command will bite one day.

I often see ack recommended by word of mouth but unfortunately I feel it's between programmers that don't understand the Unix command-line enough to instruct grep, find, xargs, etc., sufficiently accurately to do what they intend and ack has the allure of doing the right thing, though often slowly, as you say. GNU grep's -I option to ignore binary files for example, or -boa to search binary files.

Once the standard commands are learnt then by all means use ack if you understand the trade-offs and can fall back to the normal way when on another system or when ack's insufficient.

What do you think is doing the expansion of the asterisk? It's the shell, not grep, and is called globbing. http://en.wikipedia.org/wiki/Globbing

The reason there are files that start with a dot is that ls(1) and globs starting with an asterisk ignore them by default. ls needs -a (all) to show them. Some shells, but not bash, provide a globbing syntax for the recursive expansion you think you require here.

But if, as normal, you want to grep recursively down from the current directory then that's what you should specify; just pass grep one path to search, dot, the current directory.

    grep -r foo .

This is very basic knowledge of the Unix command line for a programmer and I highly recommend the classic text _The Unix Programming Environment_ by Kernighan and Pike to learn the philosophy behind Unix. It has nothing on window systems, ssh, etc., nor should it have as that's modern-day noise that hides the essence. It and Kernighan and Ritchie's _The C Programming Language_ were the key books every starting-out Unix programmer read. http://www.amazon.com/exec/obidos/ASIN/013937681X/mqq-20

Yes, that's globbing, but I was wondering what the OP meant by argument expansion. It could be just globbing, or include globbing but extend to variable expansion, braces, command substitution... It's hard to put a case that having the shell do these things is the right way to do it without understanding the OP's point clearly.

> In Grep grep -R 'some term' * , in Ack ack 'some term'. The -R tells grep to search through all directories and subdirectories while the * tells it what types of files.

No, that's not how it works with grep. The shell is expanding the glob * to all the things in the current directory that don't start with a dot and that's what grep sees. It then reads each of them in turn or if they're a directory it descends into them recursively; the * plays no further part in the descent.

Please define "argument expansion".

No, have a skim of the top-level comments on this post or others. It's not simple time-based ordering, popular comments get pushed to the top. Freshness is a factor, else all new comments would be near the bottom with un point, but as all things age it becomes nearly all score. The source for the forum used to be available in the Arc language tar file, perhaps it still is.

There's no need to "wait for a bit". Just go back and reload the page in order that you have fresh fnids that stand a chance of still being in the cache when you click the link.

It was a lot worse in that past but pg cut back on the number of fnids being generated, switching to more conventional methods. There's still quite a few around though and obviously increased traffic, meaning more new fnids to store, puts pressure on the cache.

It's the top post when I visit the story so it's presumably got more than all the others, including me?

I'm unclear what you're suggesting but your up-votes suggest I'm alone. :-) The fnid (function ID) is the index into the cache storing the continuations. It's this cache that's dropping `old' entries as new ones are added. Depending on how busy the site is, that takes a varying amount of time.

No, it's a bug, a design flaw in using continuations. See my other comment. If it was by design then the links wouldn't continue to work for longer at quiet times on the site; they do simply because old continuations haven't been flushed to make room for new ones.

Yes, that's right, but if you look at the page source you'll see fnid used elsewhere too, e.g. "add comment" IIRC. It's annoying to have typed a comment, hit add, only to find the continuation has been flushed from the cache at the server.

This is an old problem due to the use of fnid to refer to a continuation. http://news.ycombinator.com/item?id=164254

(The poor formatting of sed is caused by the post being made dead; it triggered a re-submission of the content causing corruption.)

Yes, sometimes when it's a particularly large transfer I want a progress meter but I normally don't so it's in the way; perhaps when we all had modems. And from a script I'd still want to use -sS instead of -s because although the script is obviously checking curl's exit value the user wants to see curl's specific complaint before the script's own knock-on diagnostic.

    $ curl -s does.not.exist; echo $?
    6
    $ curl -sS does.not.exist; echo $?
    curl: (6) Couldn't resolve host 'does.not.exist'
    6
    $

I rarely find I use curl's -s without its -S, e.g. -sS. It seems curl's design is flawed in its definition of -s; perhaps it's historic and it was too late to change it.

Thanks for clarifying the question. To learn comp. sci. read Aho and Ullman's excellent C edition of Foundations of Computer Science. (That's Aho as in awk.) What you need for a good grounding all in one place. You can still pick up a paper edition if you want but they've also made it available as PDFs.

http://amazon.com/exec/obidos/ASIN/0716782847/mqq-20 http://i.stanford.edu/~ullman/focs.html

lcc(1) the C compiler. As well as having readable C source, you'd learn something about the innards of C, how it is implemented, and there's a good accompanying book by Fraser and Hanson that covers the complete source as a "literate program". https://github.com/drh/lcc/blob/master/src/lex.c http://www.amazon.com/exec/obidos/ASIN/0805316701/mqq-20

I found I couldn't enter my password in unusual situations, e.g. holding the keyboard in one hand, typing with the other. I finally cottoned on that my fingers' muscle memory was typing the password consistently but it wasn't what I thought it was; it had been corrupted by similar N-grams in Unix commands from the moment I'd first entered it twice to passwd(1).

I wasn't suggesting reading a label. One measures the visible picture in real life, e.g. ruler, and calculates the DPI. CRTs didn't have a label on the back and, anyway, one could adjust the picture size.

One uses

    Option "DPI" "96 x 96"

in an xorg.conf or similar file; this overrides DDC from the monitor. Note, not all monitors have the same density of pixels in both directions. https://wiki.archlinux.org/index.php/Xorg#Display_Size_and_D... has more.

I agree, good article.

A sort -n is also required before the uniq since server logs have the time of the request but are printed when the response is complete so they're not necessarily increasing.

I don't think this would be necessary if folks ensured their X server's Screens' resolutions were configured correctly.

    $ xdpyinfo | grep -A 2 '^screen #'
    screen #0:
      dimensions:    1920x1080 pixels (483x272 millimeters)
      resolution:    101x101 dots per inch
    $

The all X clients would know how many pixels represented a physical measurement on the screen.

Unsure why the downvote since the original is wrong. To be clear,

    cut -d: -f3- | sort | uniq -c | sort -k2 -n

would be sorting the output of uniq(1) by the password, treating them all as numeric. Depending on one's locale that gives results like

      1 00auditt
    100 babygirl
      1 00beetle

or

      1 100671105192
      1 100997162005jm
      2 102030405060
      1 102990091404

Is it mere coincidence that password `123456' is the most frequent with exactly 1667 occurrences?

Isn't the sort a bit odd too? To sort by uniq's frequency it's more like

    sort -k1n,1 -k2

What's the input to that? Is it lines like

    133438:remia.eu@hotmail.com:combinate