Interesting, though I'll probably won't try it in bash

I’m still waiting for a shell with a parser as great for natural language as discworld mud was.

$ ls every second jpeg in first red folder in my backpack

AppleScript offers a NL style where you code using an english language description of an imperative syntax.

At first it seemed cool, but I quickly found it to be perverse and incomprehensible.

These samples are from Apple's Guide:

set numClowns to 5

--result: 5

set myList to { 1, 2, "four" }

--result: {1, 2, "four"}

tell application "TextEdit"

    set word1 to word 1 of front document

end tell

--result: some word

"DUMPtruck" is equal to "dumptruck" --result: true

considering case "DUMPtruck" is equal to "dumptruck" end considering --result: false

I DID NOT MAKE THIS UP

on raiseToTheNth(x, power)

    set returnVal to x

    repeat power - 1 times
        set returnVal to returnVal \* x

    end repeat

    return returnVal

end raiseToTheNth

The good news is that you can control an app as if you are interacting with its GUI and all the features are in there somewhere, somehow.

tell application "Finder"

    ignoring application responses

        empty the trash

        -- other statements that ignore application responses

        considering application responses

            set itemName to name of first item of startup disk

        end considering

        -- other statements that ignore application responses

    end ignoring

end tell

The bad news is a syntax from hell and how do you discover the available idioms?

The facility can be turned into an abomination when you interface from a shell using the osascript shim.

It's so bad that if I have to use it I can't help but fall in with it love because a working script seems like a minor miracle to be recorded in a religious tome of divine encounters.

I agree, the "natural" syntax is awful. Worst of both worlds. Terrible for experienced programmers because the syntax is so bad; terrible for beginners because it pretends to be natural but isn't.

Fortunately they offer a (barely documented) JavaScript alternative these days.

Here is the code from words.sh

   cat /dev/stdin\
 | tr 'A-Z' 'a-z'\
 | sed 's/[^a-z\.]/ /g'\
 | tr -s ' .'\
 | sed 's/\./ \. /g'\
 | tr -s ' '\
 | tr ' ' '\n'\
 | grep -v '^$';
    exit 0;

Isn't that a Useless Use Of Cat? It works without the cat and the first pipe character.

Similarly:

     cat moby-dick.txt | ./words.sh > words.txt

This could be:

     < moby-dick.txt ./words.sh > words.txt

cat is for concatenating files

true, though i think the code style focuses on readability

Exactly

I don't get the anticat crusaders. The overhead of a `cat` command surly is entirely negligible ?

    cat moby-dick.txt | ./words.sh > words.txt

I much more readable to me than

    < moby-dick.txt ./words.sh > words.txt

In the `tr` case I kinda agree, but there is a niceness to the flow when all the transformation steps are aligned like that.

> cat is for concatenating files

The real world disagrees.

It's nice to know that `< file` work though. If the input of an pipeline is what's varying writing it like `{ command1 | command 2 } < input.txt` make it slightly more convenient iterating on since changing the last word is more accessible after getting the command from history. (turning on noclobber to avoid accidentally typing `>` to be safe)

Great comment, strongly agree.

It's been wisely pointed out elsewhere that pre-pending an empty cat saves the need to futz with the first stage syntax when reusing the pipeline. It serves a syntactic function.

Strongly agree.

It's certainly a useless use of /dev/stdin.

Great to see a post of mine shared and commented here on hacker news! Never happened before and I'm glad for that. Thank you all