Re: Lua as replacement for Bash scripting

[Hisham <hisham.hm@...>]

On Tue, Jul 6, 2010 at 11:47 PM, David Manura <dm.lua@math2.org> wrote:
> On Tue, Jul 6, 2010 at 8:52 PM, Hisham <hisham.hm@gmail.com> wrote:
>> ...given that io.popen can only do reading or writing but not both...
>
> Lacking anything else, bidirectional piping could be implemented by
> writing to a temporary file.  I recall discussions on this problem in
> the past, e.g. [1].
>
>  [1] http://lua-users.org/lists/lua-l/2007-10/msg00241.html
>
>> The -pipe trick felt like
>> a neat way to trigger evaluation after a chain of __call's, though.
>
> That's the http://lua-users.org/wiki/MethodChainingWrapper pattern.
>
>> However, I think a number of the things we use pipes for in shell
>> script (grep, wc, sort and the like) can be reimplemented as pure Lua
>> functions in this library, or would simply turn into things like
>> table.sort in Lua scripts....
>> I believe that instead of focusing on duplicating sh features, it's
>> more important to make it easy to manipulate data from external
>> commands (a few utility functions to make iterators or tables out of
>> the outputs could go a long way).
>
> Accessing a shell interface via a programming language seems to me
> analogous to accessing an SQL database via a programming language.
> So, you have some functions for manipulating SQL strings, particularly
> quoting values into SQL strings.  Then you have functions for
> executing those SQL strings and reading the result back in various
> ways, such as all at once into a table or incrementally via a
> statement handle.  Unfortunately, the concept of bind parameters (like
> LuaDBI [2]) which avoids quoting doesn't apply in shells, nor for that
> matter in many database drivers either (luasql), except maybe in a
> limited way via input/output pipes which can accept unescaped data.

True. And proper quoting can be a pain in shell scripting -- more
often than not scripts break when given filenames with spaces, etc.
When you start passing data around in complex shell scripts,
especially when manipulating arrays, it can get pretty hard to get
quoting right (and in some cases near impossible, barring some really
arcane hacks using eval and the like). Of course, at this level of
complexity you shouldn't be using shell script anyway, so that's what
I have in mind here (system management scripts that do a lot of
interfacing with external commands -- that's just my personal itch,
though).

>  [2] http://lua-users.org/lists/lua-l/2009-02/msg00322.html
>
> I don't see the benefit of `pipe.ls("/dev").grep("^sd.*")` compared to
> `exec "ls /dev | grep ^sg.*".  This reminds me of some wrappers around
> SQL that add a layer of bloat.

Agreed. That's why I said my focus wouldn't be duplicating shell
constructs. I would see myself using this kind of shell wrapper more
for things like, say, shell.mplayer(file, unpack(options)).

>>> Do you think that we need to support non-POSIX environments? (Since
>>> you need this module for LuaRocks, I suppose that you do...)
>
> I think the general problem we're often trying to solve is
>
>  (1) There are functions missing or not readily accessible in the Lua universe.
>  (2) There is a wealth of functions in some other universe such as
> some OS shell (sh, Cygwin/MSYS, and don't forget Windows PowerShell)
> or some other scripting language (Python/Perl/Ruby).
>  (3) We prefer simple interfaces over performance in accessing that
> other universe via Lua.  Sending text strings back and forth if it
> allows us to avoid compiling/installing anything is fine.
> os.execute/io.popen often do this, but other ways sometimes include
> sockets, named pipes, or things like www.gtk-server.org.
>
> Some implementations of http://lua-users.org/wiki/SleepFunction illustrate this.

That's one way of looking at it -- quickly adding stuff that's missing
in Lua. Another perspective is the one originally brought by
Alexander, which is to try to use Lua to write scripts as quickly as
we do in *sh. Both are valid goals and have a lot of overlap.

-- Hisham