command line arguments

[gonsie]

The original Lua hostlist has a slightly different set of command line arguments. This is taken from the help text on quartz (hostlist -h):

Usage: hostlist [OPTION]... [HOSTLIST]...

  -h, --help                   Display this message.
  -q, --quiet                  Quiet output (exit non-zero if empty hostlist).
  -d, --delimiters=S           Set output delimiter (default = ",")
  -c, --count                  Print the number of hosts
  -s, --size=N                 Output at most N hosts (-N for last N hosts)
  -e, --expand                 Expand host list instead of collapsing
  -n, --nth=N                  Output the host at index N (-N to index from end)
  -u, --union                  Union of all HOSTLIST arguments
  -m, --minus                  Subtract all HOSTLIST args from first HOSTLIST
  -i, --intersection           Intersection of all HOSTLIST args
  -x, --exclude                Exclude all HOSTLIST args from first HOSTLIST
  -X, --xor                    Symmetric difference of all HOSTLIST args
  -R, --remove=N               Remove only N occurrences of args from HOSTLIST
  -S, --sort                   Return sorted HOSTLIST
  -f, --filter=CODE            Map Lua CODE over all hosts in result HOSTLIST
  -F, --find=HOST              Output position of HOST in result HOSTLIST
                                (exits non-zero if host not found)

 An arbitrary number of HOSTLIST arguments are supported for all
  operations.  The default operation is to concatenate all HOSTLIST args.

Note that capital S is sort, lowercase s is size.

We should either maintain identical commands as lua-hostlist or clearly document where py-hostlist is different.

[cmoussa1]

This has been fixed; sort() in py-hostlist now has a command line argument "S" to maintain consistency with lua-hostlist.

[gonsie]

We are still missing:
-q quiet, -d delimiter, -s size, -x exclude, -X xor, -R remove, -f filter

[cmoussa1]

Do you happen to know the function of -q quiet? From playing around with it I am not sure of what it does exactly; does it just take the hostlist input and store it?

[cmoussa1]

Also, I'd love to get your opinion on this, but I am sort of hesitant to implement a filter function for our hostlist; the reason being the major security flaws that eval(), the Python's way of executing input as code, possesses on computer systems. It could easily be used to interact with the system that goes past the program's original intention and could be very dangerous. What do you think?

[gonsie]

Hmmm, I'm not sure why quiet would be used. The help text "Quiet output (exit non-zero if empty hostlist)." implies that if a hostlist is empty then exit with 0... otherwise exit with non-zero or 1.

Using it on quartz, it seems that -q just suppresses the output and makes it return 0 no matter what. Maybe @regier1 has some insight?

[gonsie]

As for filter, maybe @becker33 has some insight about eval

[philregier]

I think this is just confusing wording.

Quiet output (exit non-zero if empty hostlist).

Should really be something like (but possibly more than just)

Suppress output and errors, but not exit codes

That said, I have yet to find any error output; just nonzero exit codes. I think some historical applications would interpret "-q" to suppress exit codes and stdout/stderr but I have no idea whether this was a factor in the lua-hostlist wording.

[philregier]

FWIW, I think the filter option does not need to make any promises that it cannot execute dangerous code; however, I think this option is unlikely to be used (at least right away) and will be very difficult to unit-test; besides, if the idea is to map python code then you have to deal with the fact that python is not designed to inline cleanly.

It seems to me more useful to have a similar option output its data in a python-friendly format, like json or some kind of pickled dictionary, for ingestion by another program, but I think that's another angle on which @becker33 could offer some insight.

[gonsie]

The conclusion of discussions with Phil and Greg:

Do not implement -f, rather print a warning that this feature is unsupported (and maybe direct the user to file an issue here).