Re: Lua as replacement for Bash scripting

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

On Tue, Jul 6, 2010 at 7:19 PM, Alexander Gladysh <agladysh@gmail.com> wrote:
> On Tue, Jul 6, 2010 at 21:10, Hisham <hisham.hm@gmail.com> wrote:
>
>> I've been following this thread with interest, and it seems some stuff
>> from the luarocks.fs modules serve similar purposes to what has been
>> discussed here. Perhaps it would be a good idea to join these efforts
>> and produce a shell utilities module (the LuaRocks modules try to use
>> stuff such as LuaFileSystem when available or command-line tools as a
>> fallback).
>
> I second that.
>
> I'm willing to donate a bit of my time to this project — the results
> could be useful.
>
> Lets design the interface first.
>
> I think that it should be not a single module, but a family of modules.

Yes, most likely. I agree there should be at least one separate module
name for the magic __index trick, so we don't have name clashes.

> At least these three:
>
> -- String: expansion, escaping
> -- Path manipulation
> -- Process execution, output redirection and piping.

I played around a bit here with piping, and given that io.popen can
only do reading or writing but not both, we're limited in what we can
do to emulate shell pipes -- I think we'll have to end up using
constructs that actually build shell pipes (ie, os.execute("foo |
bar")). My quick experiments follow attached. The testpipe.lua example
doesn't fully work, because I forgot that #pipe doesn't work because
you can't override # for tables in Lua 5.1. The -pipe trick felt like
a neat way to trigger evaluation after a chain of __call's, though.

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

> Do you think that we need to support non-POSIX environments? (Since
> you need this module for LuaRocks, I suppose that you do...)

On LuaRocks portability: luarocks.fs started its life as an
abstraction frontend for Unix command-line tools in order to allow
LuaRocks to manipulate the filesystem without any Lua modules
installed. LuaRocks then gained Windows support quickly by using
UnxUtils, which are Win32 builds of those command-line tools. Later, a
new backend based on Lua modules (LuaSocket, LFS, lposix) was written.
This layered approach is a bit of a maintenance burden (I'd really
like to dump the command-line-tool based support and just use Lua
modules -- support is modular for each piece, so testing various
combinations is a pain), but it's a really nice way to bootstrap
LuaRocks.

For this "shell programming module project", I think the "process
execution module" could be written in pure Lua using os.execute and
io.popen, and the "general utils module" could be written using
LuaFileSystem for portability. Using lfs directly in scripts can be a
bit too low-level at times (for example, luarocks.fs offers functions
such as fs.copy, fs.move and fs.recursive_delete). LuaRocks also
offers a pure-Lua module called luarocks.dir with things such
dir.dir_name and dir.base_name, which also save a few forks.

-- Hisham

Attachment: pipe.lua
Description: Binary data

Attachment: testpipe.lua
Description: Binary data