HN Explorer

13 comments

[ 4.1 ms ] story [ 68.0 ms ] thread
Manchit
Interesting, though I'll probably won't try it in bash
totetsu
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

_wire_
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.

IshKebab
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.

kwhitefoot
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
olejorgenb
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)

_wire_
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.
jwilk
It's certainly a useless use of /dev/stdin.
massimo-nazaria
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