ralph

They probably think they invented sex too. ;-)

Memorisation isn't the issue. Knowing the tools available and their options is. That comes with study. Unix command line is a boon for problem solving and experimentation, just go and read Jon Bentley's _Programming Pearls_. One can't Google for what one doesn't realise can be done.

The constraints of the time shouldn't be confused with their recognition of the power of notation.

Also, based on the poor advice of this thread's subject, surely one should always write /almostall in one's DCL script for clarity and to lessen the chance of ambiguity as the command evolves? grep's -i is only ever going to mean -i.

VMS died, DCL was often ridiculed, its over-verbose style was a part of that. Its lack of power played a larger part.

Aside,

    sed -n /re/p

is grep. sed's default is to print every line at the end of the script, -n says not to. Larry Wall rightly had perl(1) inherit -n along with perl's -p.

The comment is needless noise that the reader must check for correctness and then determine whether it or the code is the intended behaviour when they differ. The same is unfortunately true of many comments.

BTW, you've probably a bug in your regexp because you like to needlessly and wrongly escape a dot without knowing the regexp syntax you're using. Assuming you don't intend

    $ grep -Eo '[\.]' <<<\\
    \
    $

that is. :-)

(curl's -s should be accompanied by -S IMHO, and it's brain-damaged in not having that behaviour under the one option.)

Is that a signed integer or unsigned? How many bits? What's the lifetime of i? One needs to know more than is inferred by a few characters. Seeing the long options just makes you think you understand what it's doing without knowing what it does. The latter comes from study; there's no short-cut. Fortunately, Unix is worthy of study unlike for example the Windows API.

Then you don't use Unix, you merely enter a few canned commands to perform a limited set of actions. You are not making it work for you.

Unix is in no way perfect, for that look to Plan 9. ;-) But just as one should try and understand the idioms and style of a programming language rather than write Pascal in it regardless, so one should try and embrace Unix then suffer and learn from its warts rather than write VMS DCL in it.

And yes, brevity is pretty fundamental to its early culture. Unix was created by mathematicians and scientists that were using it every work day to get stuff down and they recognised and extolled in their writings the power of notation. Imagine maths without superscripts, Σ, etc. So it is with Unix. More wordy notations existed in other OSes at the time, and more noisy commands, e.g. VMS would tell you that "dir/size/owner/prot foo." completed normally, even though that's hopefully the norm. It gets very annoying. :-)

It's not necessarily your choice. [\.] in sed is a two-character character class.

You are not a Unix user. You don't know Unix's commands and their common options. If the article is aimed at you and people like you that read your scripts then it's fine but it's akin to commenting "dir /w" in a DOS batch file to explain its purpose. Unix users should not following the article's advice, they should be embracing Unix's style and ethos; it's part of what's made it such a success.

BTW, a month of using Unix should have a Unix user knowing what ls's -t and -r flags do, along with -a and -l they're some of its most commonly used.

This is silly. I can type grep's "-iv" before your auto-complete has enough info entered to complete the first option alone; "--i<Tab>" would beep, needing a "g" to continue.

Then you could be introducing errors into your regexps. \x doesn't mean a plain x instead of the metacharacter x in all cases. Don't ship code you don't at least think you understand.

> you said "There isn't and shouldn't be any hard fast rule for this"

No I did not. You're confused as that was someone else. :-)

Do not needlessly escape. Only escape what that flavour of syntax needs you to do. What you may think is a needless escape may actually give different behaviour.

    $ sed 's/[x\.]/y/g' <<<'x.\z'
    yyyz

This is very bad advice. I won't thank you for making me check GNU grep's --ignore-case is precisely the same as the very well-known, POSIX'd, -i. And ditto for all the other verbiage that clutter and obfuscate the script's intent.

Short options should be used where they're the more typically known and standardised. Long options are for the unusual.

    grep -iv
    sed -n
    tr -dc
    awk -f
    ls -tr
    comm -23
    tail -n

No, that's wrong, a reader that knows his onions, e.g. me, will be puzzled as to what the writer's intent was and spend time investigating if there is an error before deciding the writer needs to spend more time studying his onions.

I'm surprised Hacker News readers are even having this conversation. :-) Kernighan and Pike's excellent _The Practice of Programming_ addresses it early on; chapter one _Style_, section one _Names_. It includes suggesting length should be inversely proportional to scope and that “clarity is often achieved through brevity”. http://amazon.com/exec/obidos/ASIN/020161586X/mqq-20 http://cm.bell-labs.com/cm/cs/tpop/

Firefox will show me what CSS applies to each entity and what attributes result. I'd like something that gave me the same information textually so I can tweak the CSS, e.g. simplifying specificity without intending to change the end result, and check for changes, e.g. diff(1). Anyone know of such a thing?

Yes, the Right-Left rule is the one to use; I first read of it in Anderson & Anderson's _Advanced C: Tips & Techniques_. Having that simple rule, there's no need to struggle over qsort()'s declaration and others, or create unnecessary, one-use, typedefs.

I eschew aliases, using them only when necessary, e.g. when changing directory. There's many places in Unix where a knowledgeable user can kick off a command and in many aliases won't work. This gets annoying and is solved by having ~/bin/... wherever possible. The overhead is minimal, many being one-line of code starting with exec.

A shell and all the tools that come with it; grep, sed, awk, diff, sort, uniq, comm, paste, join, cut, find, ... :-)

I'm not sure that works well with SPDY; it would prefer the same domain?

(Fails if a directory has a linefeed in its name followed by a 'd'. :-)

What benefit does

    :!sudo tee %

have over doing it at the command line other than filling in the current filename for you? I suspect the original poster meant something like "gg!Gsudo tee %".

Yes, either type G when presented with the top of the file or pass +G on the command line. It will then read all the intervening file to calculate the line numbers, and tells you it's doing this and to interrupt it to stop. To prevent it doing this in the first place use the -n option.

"less -n huge_file" and then G only reads the start and end of the file. Type G again to move to the latest end of the file if it's growing.

yes(1).

What vi mode is that entered in?

For the first I do defaultdict(bool) ;-)

AIUI in some areas if the business claims for part of the main residence as a home office over a prolonged period then Capital Gains Tax can be due on that same fraction if there's a profit when the house is sold. IOW, it's not a free lunch.

Well, I suppose given it will cycle it can be simplified to an array indexed based on t; still don't think that's playing the game though.

Re-formatted for reading,

#include <math.h>

    int main()
    {
        int v, i, z, n, u, t;

        for (v = -1;;) {
            for (n = pow(1.05946309, "CWG[Cgcg[eYcb^bV^eW^be^bVecb^"[++v & 31] + (v & 64) / 21), i = 999;
                i;
                putchar(128 + ((8191 & u) > i ? 0 : i / 8) - ((8191 & (z += n)) * i-- >> 16))) {
                u += v & 1 ? t / 2 : (t = v & 6 ? t : n / 4);
            }
        }

        return 0;
    }

Can this be simplified to just use an incrementing t? Otherwise I'm not sure it's in keeping with the spirit of the original. :-)

BTW, the increment and use of v without a sequence point in between may bite.

PDF is provided on the book's page I gave above. You're correct, small mark-up changes are needed to make use of the PDF-linking macros now available that weren't then.