openresty / resty-cli

Fancy command-line utilities for OpenResty

Home Page:http://openresty.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

script argument handling

neomantra opened this issue · comments

commented

When passing arguments to resty that are intended for the Lua script, a standalone -- is needed if any of the arguments are prepended by --.

I was surprised by this when I made a shell script that invoked resty. The workaround for a shell script is to include -- in the hashbang line like so:

#!/usr/local/openresty/bin/resty --

Here are some examples of this from the command line:

$ /usr/local/openresty/bin/resty -e 'for k,v in ipairs(arg) do print(k,v) end' -- help
1help

$ /usr/local/openresty/bin/resty -e 'for k,v in ipairs(arg) do print(k,v) end' -- --help
1--help

$ /usr/local/openresty/bin/resty -e 'for k,v in ipairs(arg) do print(k,v) end' help
1help

$ /usr/local/openresty/bin/resty -e 'for k,v in ipairs(arg) do print(k,v) end' --help
resty [options] [lua-file [args]]

Options:
    -c num      set maximal connection count (default: 64).
    -e prog     run the inlined Lua code in "prog".
    --help      print this help.
    -I dir      Add dir to the search paths for Lua libraries.
    --nginx     specify the nginx path (this option might be removed in the future).
    -V          print version numbers and nginx configurations.
    --valgrind  use valgrind to run the underyling nginx

    --valgrind-opts     pass extra options to valgrind

For bug reporting instructions, please see:
<http://openresty.org/#Community>

Maybe this should be documented? Or maybe this issue is that documentation?

@neomantra For the -e use cases, the -- is definitely needed to distinguish options for the Lua script and options for the resty utility itself. Regarding documenting this, sure, we could. You're welcome to submit a pull request to patch the README file. Thanks!

Regarding the shell shebang line, I'm not sure what your shell script looks like. The Lua interpreter does not allow the sheblang line anyway. But I think maybe we can make the resty utility automatically strip the shebang line before feeding it into the Lua interpreter. Will you provide a patch for this feature as well?

Thanks a lot!

commented

I'm specifically using alt_getopt to handle arguments. I have a script that looks like this

#!/usr/local/openresty/bin/resty --
-- filename: test.lua
local alt_getopt = require 'alt_getopt'
local opts, optind, optarg = alt_getopt.get_ordered_opts(arg, 'h', { help = 'h' })

and I'm invoking it like this:

$ ./test.lua --help

Of course my script is much more elaborate , but the shebang line is working fine. I think the LuaJIT lexer takes care of it: http://repo.or.cz/w/luajit-2.0.git/blob/refs/heads/v2.1:/src/lj_lex.c#l389

If you are thinking of something else or still think there needs to be some argument processing in the resty utility, let me know and I'll check it out.

Sure, I'll work on a documentation PR.

@neomantra Yeah, LuaJIT takes care of it. I was talking about the standard Lua 5.1 interpreter OpenResty still supports :) But yeah, given that LuaJIT is used by default, it's not really of priority.

Regarding the very issue of --, I see what's happening now. The Perl module Getopt::Long used by the resty script incorrectly interprets the --xxx stuff after the script name argument as the options of the resty script itself. This is the expected behaviour of this Perl module but it's really wrong for our needs and should gets fixed. It requires some hacks to get around this behaviour. Will you be interested in contributing a patch for it? If not, I'll look into it later :)

Thanks for the report!

commented

I took a stab at it, but my Perl-fu is pretty non-existent. Given it is a bug, there's a workaround above and I won't update the docs (unless you want me to or you think it is intractable).

@neomantra No worries. I'll look into this :)

@neomantra Okay, the fix is much easier than I thought and is actually trivial :) Please check out the patch in commit dbcb6b4. Thanks!

commented

I can confirm this works for me without needing the workaround. Thank you!

@neomantra Glad to hear that. Thanks!