Re: scsh as scripting language

Andreas Bernauer <[email protected]> Tue, 31 Mar 2009 17:00:19 +0200
Newsgroups gmane.lisp.scheme.scsh
Message-ID <[email protected]>
[Sorry for the delayed response, my first response was eaten by some mailserver
at our site.]

Hi,

Emilio, thank you for your comments.

I think scsh' status is sad and I'd like to see it improved.

Emilio Lopes wrote:
> 2009/3/7 Andreas Bernauer <[email protected]>:
>> http://www.lysium.de/blog/archives/215-Why-I-dont-use-scsh-as-a-scripting-language-anymore.html

>> Of course, that would be too easy. scsh now thinks "-o srfi-9 -s" is
>> a single switch:
> 
> I think this is an Unix shortcoming.  Only one argument is allowed
> after the interpreter name.  That's the reason for the "meta argument".
> As a general rule you can assume that Olin is a pretty smart guy and
> knows what he does.

That's what I am afraid of: Olin is so smart, I can't follow him. From Olin's
post you mention below (http://www.scsh.net/docu/post/signall.html):

> #!/usr/local/bin/scsh \
> -dm -m proc-signal-all -e main -s
> !#

Seriously, how am I (or anybody else) supposed to remember this? Compare this to
any other scripting language:

#!/bin/sh

or even

#!/usr/bin/python

I use scripts to do some processing, eg. select or calculate something from some
pipe or file data, rearrange the file system layout, or process some server
output, etc. The tasks are either one-time-only, special-purpose or even quick
hacks.

In my opinion, scsh is not suitable for these tasks for the given reasons.

I don't want to write a whole program or a library, I just want to write some
(small) script. scsh gets in my way with its surprisingly complex syntax for
scripts and poor diagnostic messages.

>> Back to how to load some module. As you can't put it on the starting
>> line, the scsh authors did not think about some mechanism to load a
>> module from within your script (such as "(open-module srfi-9)"), as
>> every other reasonable script language does
> 
> As you mention further in your posting, the solution for this problem
> is to define a structure (module in other languages).  It's better
> practice anyway since your script can be used either as a library or
> as a script in itself.

First, as I already mentioned, I don't want to write a library, so I don't see
the need to define a structure. For me, that's like in Java, where every program
needs to be defined in a class: a lot of unnecessary syntax.

Second, the need to have a structure here is a limitation of scsh and not some
benefit. For example, I can use other Python scripts as libraries without the
need to define a module, I just 'import' them.

Third, as Olin's example above shows, using a structure still puts the burden on
me to remember the strange flags for the second line, to pay attention not to
insert stray white space in that second line and to not forget to close the
she-bang on the third line.

>> Of course, that would be too easy. Instead of locating the "wrong
>> number of arguments" error from above, I have a new error. The
>> reason is that the script uses the srfi-9 module to create records
>> ("structs" in C lingo). The script uses a switch (instead of some
>> import-statement like any other language implementation) to load
>> that module, but the interactive scsh interpreter does not care
>> about the switches, because they are in the comments.
> 
> Using a structure (and opennig it in the config package) would have
> solved this.

But even when I'd be willing to write structures, ',config ,load' and ',open'
them in scsh to debug them, my "biggest show stopper" still holds: errors don't
tell you where they come from.

I don't say you cannot write scripts with scsh.
I just say it's too complex (starting lines of a script, need to define a
structure) and difficult (no proper error messages) for me. Instead of
concentrating on the problem at hand, I concentrate on restrictions, syntax and
shortcomings of scsh.
Or better, I turn to some other scripting language which allows functional style
and is less complex.

[Or, I fix it. Oh, well.]

-- 
Andreas.