[RFC] zsh/getopx — zsh interface to getopt_long(3)

[dana <dana@xxxxxxx>]

Hey there,

In my 'consumer' shell scripts i often use the util-linux version of getopt(1),
which provides many functionality and ease-of-use benefits compared to the BSD
getopt(1), the getopts built-in, and the zparseopts built-in, by way of
getopt_long(3). The major down side to this utility is that it's rather hard to
come by on non-GNU/Linux systems.

Since getopt_long(3) itself has been portable across all of the major UNIX-like
systems for about 15 years now, it seemed like subsuming that functionality into
zsh via a module might be a decent idea. So i've done that, or at least i've got
a working prototype:

https://github.com/okdana/zsh/blob/dana/getoptx/Src/Modules/getoptx.c

I'm not a fantastic C programmer so there's probably a lot of weird stuff like
questionable allocations and temp variables, the code doesn't conform to the zsh
style guide lines, and i'm not super married to either the name or the API — but
other than that it seems to do the job. Here's a partial usage example
illustrating the current API (including the -c option, which makes it easier to
support use cases like `tail -15` by leaving adjacent numeric options grouped
together):

  getoptx -cEA argv -l help,lines:,version hn:V || return 1

  while (( $# )); do
    case $1 in
      -[0-9]##)     lines=${1#-}; shift ;;
      -h|--help)    : print help; return 0 ;;
      -n|--lines)   : validate $2 somehow; lines=$2; shift 2 ;;
      -V|--version) : print version; return 0 ;;
      --)           shift; break ;; # any remaining argv are operands
    esac
  done

Do you reckon this is something that might be suitable for inclusion into the
main project (assuming i get it cleaned up)? Or is the arg-parsing 'market' too
saturated already with the alternatives i mentioned?

(Of course, any other thoughts you might have would be appreciated too.)

cheers

dana