Re: Lua as replacement for Bash scripting

[Alexander Gladysh <agladysh@...>]

On Wed, Jul 7, 2010 at 22:59, Hisham <hisham.hm@gmail.com> wrote:
> On Wed, Jul 7, 2010 at 7:34 AM, Alexander Gladysh <agladysh@gmail.com> wrote:

>> I've set up a project on GitHub:

>> http://github.com/lua-shellscript/lua-shellscript
...
>> So, if anyone wants to contribute, feel free to do so.
...
>> Lets design API for our modules! :-)

> Thanks for the initiative! I have some thoughts but I'd rather bring
> them up for discussion before editing it there.

> * Is the module name "sh" taken? I think an important goal for quick
> scripting is to be as concise as possible. I know one can always do
> "local X = long.module.function_name" but you shouldn't need to, in
> quick scripts.

I like "sh" as a module name. I do not think that it is taken. There
is a "luash" project, but that is a different name :-)

> * Following that idea, I think most pure-Lua stuff should live in the
> main "sh" module. The idea I was playing with, which felt pretty good
> in the few examples I tried, was to have a few magic tables for
> command execution, varying in their outputs:

>   local root_disk = sh.out.df("/")
>   print("Root disk is "..root_disk:match("%d+%%").." used")

>   if sh.ok.diff("-u", first_file, second_file) then
>      print("Files match!")
>   end

> At first I added sh.ok (converts result to a boolean), sh.run (returns
> exit code), sh.out (io.popen opened for reading, returns output as a
> string), sh.inp (io.popen open for writing, takes input as a string
> through __call -- better ideas welcome).

Looks nice.

> These are not pipeable, but
> as piping has some complications I think it's better to leave it in a
> separate, to-be-defined, construct.

> David Manura wrote:
>>> And the fourth noted by Hisham is
>>> -- filesystem I/O abstraction (e.g. fs.recursive_delete)
>> which I think should be a separate module from the core shell
>> abstraction module (for quoting/exec).  The filesystem I/O abstraction
>> module would have optional dependencies on other modules like the
>> shell abstraction module, LuaFileSystem, and lposix.

> Agreed. I think we could get away with two modules, sh (pure-Lua) and
> sh.fs (with the optional dependencies).

Hmm... I, usually, do not like putting unrelated things in a single
namespace :-)

However, if we would ever feel that the "sh" namespace is too
cluttered, we may use it as an alias only: define our stuff in more
specific modules and "link" to them from "sh" for those
quick-and-dirty coders convenience.

Alexander.