matejak / argbash

Bash argument parsing code generator
Other
1.4k stars 62 forks source link

Allow ARG_LEFTOVERS after ARG_POSITIONAL_INF if ARG_POSITIONAL_DOUBLEDASH specified between them #159

Closed gdevenyi closed 2 years ago

gdevenyi commented 2 years ago

I have an implementation I'd like to write where the script functions as a wrapper, launching another program, where I'd like to be able to pass an arbitrary amount of arguments to that script. Before I do that, I may have an arbitrary number of positional inputs to the wrapper.

I'd like it to operate like so:

$ ./script <input1> ... <inputN> -- <arbitrary argument1> .. <arbitrary argument N>

I tried to implement it like this:

# ARG_POSITIONAL_INF([inputs],[input arguments],[1])
# ARG_POSITIONAL_DOUBLEDASH([])
# ARG_LEFTOVERS([arbitrary arguments to be ])

However argbash doesn't like this:

stdin:38: error: We already expect arbitrary number of arguments before 'leftovers'. This is not supported
stdin:38: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
Error during autom4te run, aborting!
matejak commented 2 years ago

In this case, the terminator (i.e. --) would be treated as a positional argument that happens to be composed of two dashes. IOW, your request is not consistent with GNU or POSIX CLI standards, so Argbash won't implement this. Argbash will happily allow you to declare the infinitely long positional argument with an appropriate help message, but there are no means how to shape the help command-line synopsis to the form that you would like to. As the feature requested is non-standard, I close this issue, but I hope that you will still find Argbash useful for more conventional tasks.

gdevenyi commented 2 years ago

Hi, I think the standalone double dash is a GNU standard, as you see it many applications, most prominantly grep,

Some details here, https://unix.stackexchange.com/questions/11376/what-does-double-dash-mean/11382#11382

Also directly in bash: https://linux.die.net/man/1/bash

A -- signals the end of options and disables further option processing. Any arguments after the -- are treated as filenames and arguments. An argument of - is equivalent to --.

gdevenyi commented 2 years ago

Seems its also in the POSIX standard: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02

Guideline 10: The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character.

matejak commented 2 years ago

You are right that -- aka terminator is standardized, but I think that the usage that you suggest would be non standard. Terminator is there to indicate that there won't be any optional arguments following it, and everything ends up being treated as positional argument, even if it looks like an option. What I understand that you suggest is to somehow separate two sets of positional arguments, as the first set doesn't have a fixed length. Terminator as defined in the standard is not there for these purposes. My earlier comment about terminator being treated as a positional argument was misleading, so you can forget about it.

gdevenyi commented 2 years ago

Maybe I'm reading the usage docs differently, from bash:

A -- signals the end of options and disables further option processing. Any arguments after the -- are treated as filenames and arguments. An argument of - is equivalent to --.

This is exactly what I want to happen in argbash. Everything after -- should end up in ARG_LEFTOVERS. I just want to make this division explicit.

gdevenyi commented 2 years ago

This pairs up with ARG_RESTRICT_VALUES as I'd like to check for validity everything before -- as being valid and allow anything after -- to end up in LEFTOVERS.