[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua as replacement for Bash scripting
- From: Eduardo Ochs <eduardoochs@...>
- Date: Mon, 12 Jul 2010 18:21:12 -0300
On Mon, Jul 12, 2010 at 2:56 PM, Javier Guerra Giraldez
<javier@guerrag.com> wrote:
> On Mon, Jul 12, 2010 at 4:51 AM, Alexander Gladysh <agladysh@gmail.com> wrote:
>> 1. Even if we would be able to design the library in such way, we
>> still should provide escaping — just in case we missed some case
>> somewhere.
>>
>> 2. Please suggest the interface for the library that avoids the need
>> for escaping. :-)
>
>
>
> the point to remember is that a posix process invocation is _not_ a
> text line; it's a list of C strings.
>
> a huge part of the pain in programming shell scripts is fighting
> against the need of the shell to parse the command line into that
> string list; therefore you get quotes, and escapes, and lots of
> variable extension rules you have to memorize. if you go the route
> of parsing a 'command line', you'll likely get the same issues.
>
> OTOH, if you keep the Lua syntax (as it seems from the latest examples
> on the thread); you don't have to worry about parsing, that's done by
> the Lua compiler. and yes, Lua does have it's own set of escaping
> rules, but these are so much simpler and saner than any shell's.
> precisely because they're limited to building strings; after they're
> built, they're threated as opaque binary data, and there's no need to
> further process them before using them to spawn a subprocess.
>
> of course, some simple templating (maybe like python's string
> interpolation) might be desirable (*); but it should be an extra
> facility, not a forced part of the data flow.
>
> that way, you don't have to worry that a filename might contain
> spaces, or quotes, or any 'nasty' characters; Lua doesn't care,
> excecvp() doesn't either (except for embedded '\0's, unfortunately)
>
>
> (*): this is what i use when i find myself using string.format() too much:
>
> function string:template(variables)
> return (self:gsub('{%%(.-)%%}', function (key) return
> tostring(variables[key] or _G[key] or '') end))
> end
Here's my 2c...
I use something like this:
ee_expand("ls")
--> "ls"
ee_expand("~/tmp/")
--> "/home/edrx/tmp/"
ee_expand("$S/http/foo/")
--> "/home/edrx/snarf/http/foo/"
ee_split("ls ~/tmp/ $S/http/foo/")
--> {"ls", "~/tmp/", "$S/http/foo/"}
ee_split({"ls", "~/tmp/", "$S/http/foo/"})
--> {"ls", "~/tmp/", "$S/http/foo/"}
ee_split_and_expand("ls ~/tmp/ $S/http/foo/")
--> {"ls", "/home/edrx/tmp/", "/home/edrx/snarf/http/foo/"}
ee_split_and_expand({"ls", "~/tmp/", "$S/http/foo/"})
--> {"ls", "/home/edrx/tmp/", "/home/edrx/snarf/http/foo/"}
I don't use the other expansions very often from Lua, so my basic
functions to invoke processes only support "$" and "~" expansions __in
the beginning of each "word"__, and they accept both strings and
tables as their arguments... and each one of my calling functions has
a variant in which "$/~"s are expanded, and a variant in which they
are not.
Some links:
http://www.gnu.org/software/bash/manual/html_node/Shell-Expansions.html
http://www.gnu.org/software/libc/manual/html_node/Executing-a-File.html
(info "(bash)Shell Expansions")
(info "(bashref)Shell Expansions")
(info "(libc)Executing a File")
http://angg.twu.net/eev-current/eev.el.html#ee-split
Cheers,
Eduardo Ochs
eduardoochs@gmail.com
http://angg.twu.net/
P.S.: I am aware that this is not a universal solution and that it
does not solve all possible problems... I know that you are discussing
what to put in a library that we would be proud to show to everyone,
but some people who just want a cute hack to put in their $LUA_INIT
file might find this useful...
- References:
- Lua as replacement for Bash scripting, Alexander Gladysh
- Re: Lua as replacement for Bash scripting, Jerome Vuarand
- Re: Lua as replacement for Bash scripting, Alexander Gladysh
- Re: Lua as replacement for Bash scripting, Jerome Vuarand
- Re: Lua as replacement for Bash scripting, Hisham
- Re: Lua as replacement for Bash scripting, Alexander Gladysh
- Re: Lua as replacement for Bash scripting, Florian Weimer
- Re: Lua as replacement for Bash scripting, Javier Guerra Giraldez
- Re: Lua as replacement for Bash scripting, Alexander Gladysh
- Re: Lua as replacement for Bash scripting, Javier Guerra Giraldez