Re: AppleScript and shell scripting
Re: AppleScript and shell scripting
- Subject: Re: AppleScript and shell scripting
- From: "John C. Welch" <email@hidden>
- Date: Mon, 30 Jul 2007 09:04:19 -0500
- Thread-topic: AppleScript and shell scripting
On 7/30/07 01:55 AM, "Mark J. Reed" <email@hidden> wrote:
> On 7/29/07, John C. Welch <email@hidden> wrote:
>> One thing I will say that seems to have been ignored is the importance of a
>> good environment. While you have advanced IDEs for many languages, including
>> AppleScript, shell is still stuck back in the realm of stone tablets and
>> pterodactyls. Perhaps if there was an environment on the level of Script
>> Debugger for shell, it would become a lot easier. I know that if I ever get
>> serious about Perl, I'll be writing another check to Mark for Affrus.
>
> The shell is not a programming language. At least, not primarily. If you're
> doing application development using the shell as your implementation language,
> you've got a lot more problems than the tool set. :) It can be done, surely -
> the appendix to the KornShell book is an implementation of the MH email client
> using nothing but ksh - but that was more of a demonstration of the shell's
> power than a recommendation for future application development.
What it was intended as, and what it has become are two different things.
The shell is both environment and "language". Were the language part
completely not true, then the idea behind *csh would have not happened.
There's no need to make it more like some other language if it isn't.
>
> The shell is, fundamentally, a program that lets the user execute other
> programs. It's the CLI equivalent of the Finder; a command like "awk '{hey}'
> file1 | sed 'there' >file2" is tantamount to double-clicking Awk, hitting
> File->Open, selecting "file1", using Awk-specific menus to perform the logic
> represented by 'hey', copying the result to the clipboard, double-clicking
> Sed, pasting the result in, using Sed-specific menus to perform the logic
> represented by 'there', and hitting File->Save and typing in "file2". (More
> or less; technically, the shell is responsible for saving to file2 in the
> example.)
The number of shell scripts that execute in a non-interactive fashion make
it both a language and an environment, ala Carlin's infamous "meatcake".
>
> Normally, in a CLI environment, you type out commands interactively and see
> the results on your screen before typing the next command. A shell script is
> a place where you can store the commands for later execution, and wrap them
> with loops or if statements or whatever to make the automation more flexible.
> Basically, the fact that most shells have all that programming-language
> goodness is the CLI equivalent of the fact that the Finder is scriptable.
> That's probably the best way to think about the term "shell script(ing)": you
> are scripting the shell.
That's still programming. Semantic denials aside, the shell is both, and the
environment for writing shell scripts is currently one step above hex
switches on a front panel and smoke signals, something that greatly
contributes to the perception that it is "hard".
>
> But since the shell dates back to stone tablets and pterodactyls, it's not
> part of some structured system-wide scripting API. The system-wide scripting
> API was called "strings", as in "you can pass strings to programs and get
> strings back out of them". At least in the UNIX world(*) there's no automatic
> way to discern what arguments the various programs expect. So in order to
> develop a full-fledged IDE for the shelll, you'd essentially have to develop a
> full-fledged IDE for every program in $PATH.
You mean like developing an IDE that deals with all the various osaxen and
what they expect, or the dictionaries for every scriptable application?
Right, totally impossible ;-)
>
> So, effectively, the shell is its own IDE. You can type commands
> interactively and see the results immediately. Modern shells even have
> completion on the names of commands and files, and you can set up some (like
> tcsh) to do completion on non-filename arguments to other programs as well.
> If that's not enough of an IDE for the task at hand, then the task at hand is
> probably best accomplished with something other than the shell.
As an IDE, the shell sucks mightily for anything but completely interactive
command entry. I honestly don't *care* about the precise definition of what
shell scripting is. At this point, it's like pr0n: no one can define it, but
we all know what it is when we see it. Shell scripting is where real work is
done, yet for some reason, and I do think it's a kind of masochism, there's
a resistance to provide any kind of modern environment FOR shell scripting.
That's inane, unless you want to keep the n00bs out.
--
"Debugging? Klingons do not debug. Our software does not coddle the weak."
- 6th most commonly uttered Klingon programmer phrase
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden