Natural language processing in Bash (2023)

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.

true, though i think the code style focuses on readability

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)

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.

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