csh programing book
Peter Schuller
peter.schuller at infidyne.com
Mon Dec 17 13:55:54 PST 2007
> Well, I was only giving my personal opinion. I've never used irb, but
> it seems to me that using any sort of OO tool as a shell would be "cruel
> and unusual", but I guess it takes all kinds, and I certainly wouldn't
> prevent you from enjoying yourself, same as I'd expect from you to mine.
The "OO" nature of it really really does not come into play here as far as I
can tell. Whatever you can imagine with perl/python/your-favorite-language is
very likely as much possible, if not more so, with Ruby.
Certainly if writing something elaborate it comes into play, but then we are
away from the shell aspect of the discussion.
Doing:
system "myfile"
does not become any more obnoxious just because "myfile" happens to be an
object in a well-defined class-based object system. Nor does the function
definition:
def myfun(param)
...
end
Become obnoxious just because Ruby happens to be OO, for some definition of
OO.
My main concern is syntax. I would love to have a shell based on Ruby, Lisp,
or some other powerful language (anything that at least allows functions to
return values other than status codes... please). But I have yet to find one
that makes it maximally simple and efficient to do the common stuff that you
use interactively - which is to run external processes.
scsh (Scheme Shell) comes pretty close; I have no objection to using it for
shell *scripting*. Neither might Ruby be an issue with sufficient API
support.
But I am not sure about using it interactively. When interactive, you don't
want to type even a single annoying character more than you have to. Or at
least I don't.
That said, scsh might be possible to tweak sufficiently. It actually manages
to combine the power of Lisp with the convenience of shell scripting pretty
well (as always, by using macros). So you have pretty low-overhead syntax
like. For example, instead of:
more myfile
You have:
(run (more myfile))
If you imagine an interactive mode where a top-level (run (...)) would be
implied (under certain circumstances), you could make that be exactly
equivalent to the normal shell version:
more myfile
This is true even with parameters; the macros are such that you need not
explicitly make them strings (so "(run (ls -l /))" is valid for example).
I especially like the integration as soon as you want to do something slightly
intelligent. E.g.:
(run/strings (mystuff --list-something /path/to/db))
Yields an actual list of strings (one per line) that you can touch, pet and
otherwise have your way with even if you want to do something other than
piping it to the next process.
Not to mention having higher order functions at your fingertips...
In short, I would just love to have a single language for both tasks, not
having to "switch" from one to the other after some threshold of script
complexity. Unfortunately scsh has some issues (e.g., freebsd port is marked
as broken om amd64 right now), so I dunno about counting on it being
available everywhere.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller at infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20071217/d7e480f8/attachment.pgp
More information about the freebsd-questions
mailing list