al_form2000

So how does one audit this Behemoth?

Tl;dr: "Sell your customers what they want, make them pay what you say, be sure they're rich enough."

Best paradigm busting advice in business after "If you can secure just 0.1% of the chinese market, you'll have 5 milion customers" and "Always remember: profit is revenue minus expense".

So what year are we in, again?

Shallow piece. Tl;dr: haters gonna hate.

For verly large values of one hour.

The analogy between coding and music is actually quite flawed.

If school is currently teaching this, it is seriously failing its mandate. This does not mean that using sort(3) as a solution to a sort assignment should be acceptable.

> "hacking" aka "going fast and breaking things" is so glorified

The two sides of your equation do not equate at all.

<<I don't mean that we should not be political in our actions, today.>>

Y not?

<<...early hacking was a-political is because hackers were fairly despicable a-social people.>>

That is what made it fun.

The RCE bug appears to be restricted to fast_cgi:

https://bugs.php.net/bug.php?id=78599

That was what came to my mind, actually.

That (cultural differences in thought patterns) is indeed an interesting take (I'd like to hear what Larry Wall has to say about it). I do think it would be best addressed at the background level (say predicate logic or somesuch) than at a programming language level (which is more of a consequence).

Unfortunately, the "unfairness" thing has hijacked many subthreads and it takes the proposal at face value (as in "Wouldn't it be cool if any programming language was available in localized form, charset, keywords and kaboodle?" - no it wouldn't) .

Assuming there is merit to the idea that the Latin charset gives unfair disadvantage for people from other cultures (I think not(1)), then a language should be formed from a culture neutral alphabet - say, klingon. It better have a number of glyphs in the vicinity or 30 or so (for typing ease) no funky char combining rules (for reading ease) etc. And it would still need guidelines for naming functions, variables, not to mention pronouncing them (these could of course be localized rules) etc. My guess is that it would be a Latin like script, only with different glyphs. And of course, all var and function names would be hopeless gibberish, unless we all decide to become klingon/whatever fluent.

(1) At the very least, someone should explain why the rise of - say - the russian and indian programmers, given the unfair barrier.

You're not barred, you have to learn relevant combinations of 26 symbols. If you cannot do that, I doubt you'll become proficient in programming anyway. OTOH,knowledge sharing in the field would be severely impeded if every piece of source code was localized to the wim of the author/marketplace/whatever.

Non native speakers would'nt be able to take those jobs anyways if names were untranslated and in local script.

As I remember, they had also localised symbolic "constants" so a format spec fed to (some date function) was 'dd/mm/yyyy' for english locale, but 'gg/mm/aaaa' for the italian one . God help you if you had (I did) some combination of - say - English Excel and italian OS (as I remember you got english function names but italian 'constants' as in DATEFORMAT('gg/mm/aaaa'...) with nonsens errors if you used 'dd/mm/yyyy').

An asinine idea indeed.

I remember writing the title as

    ALL_CAPS => sudo all_caps

So it appears something did actually change it.

As mentioned above, you don't need to retype:

        $ foo bar baz<cr>
        ^P^A<esc>u
        $ FOO bar baz<cr>

As for ^T, I'd wholly forgotten about bind, inputrc and all that- but of course both your proposal and the above can be put into an inputrc macro and bound to a key. However the all caps version is shorter when you remember you need sudo in the first place ;).

        $ foo bar baz<cr>
        ^P^A<esc>u
        $ FOO bar baz<cr>

That's three keystrokes less - even for the history (!!) version. :-)

I used to hate it that my bank requires a physical trip to the branch for cred reset. No more.

I love it when arguments are so deeply grounded in facts.

That may never, ever happen. Don't you know that only old awkward male hippy sin^H^H^H (are reported to) make/say unacceptable things?

What a nice piece of backstabbing. Class.

Oh, under one fifth? Peachy.

This has prompted me to look if floppies are even still available for purchase -they are (as are USB floppy drives). Also pretty expensive, at 1.5 euros apiece.

Aw, right. I'd forgotten about IPC::Open3. Because I did not want to think about it, mostly (and so, I usually do exactly what you say people do :-) )

> Perl is probably the closest but still has some warts related to redirection.

I wholehartedly agree on perl but can you expand on the redirection warts? I seldom had problems with perls' FHs, while, on the contrary I seem to be unable to wrap my head around the contorted syntax involved in bash's handling of descriptors - especially when more than 2 handles are involved.

Yes - and no. I find the shell is a useful glue language for procedural tasks (do this, run P1, then P2, and if blah) which can/had better be logically simple but rather long and heavy on the system interaction side.

For these, being able to avoid the various $(echo... |sed) can be refreshing. Beside, the book makes for a nice repository of techniques.

Very nice recipes. I'd avoid shadowing actual executables with bash function names (see head in the book) as a harbinger of great grief.

DRY in spades. More peace & power to the author and all that. However, as a putative user of the project, I'd like to know what would I gain by adopting it. Last time I looked, that was part of use case discussions. I'd happily settle for 'No gain, but it's been a great learning experience' - that's not as it was presented, though.