Re: Handling short and long options

[Alex fxmbsw7 Ratchev]

an edge case where = doesnt fit is complex space and = containing arguments
arg 1 'foo bar 3=4 blah' .. then whats the opt to check for in that mess,
... i dont like this = instead of on own arg style

On Tue, Sep 7, 2021, 06:38 Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com> wrote:

> i mean it can be seen as 'words / arg parser'
> the - and -- are old style usage addons to it
>
> On Tue, Sep 7, 2021, 06:36 Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com> wrote:
>
>> well see what i coded again, around what i meant by how i like to do it..
>> just its on phone termux so its more of a one liner
>>
>> but that is yet without = separator, arg ( space ) separator, .. thr = i
>> didnt figure enough, however i think it has bugs
>> arg 1 'arg' arg 2 'else' what -- and =  ..  :p
>>
>> ~ $ declare -A arg ; declare -i id ; declare -ai takes ; declare -a cmd ;
>> add() { declare code a ; declare -i take ; takes[++id]=$take cmd[id]=$code
>> ; for a ; do arg[,$a]=$id ; done ; } ;   code='printf 1yes\\n' add 1 4 ;
>>  take=1 code='printf 2:%s\\n "$1"' add -o --opt ;   parse() { declare -a
>> a=( \  "$@" ) ; declare -i i e=$# ; declare idd aa ; while (( ++i <= e )) ;
>> do aa=${a[i]} idd=${arg[,$aa]} ; [[ -z $idd ]] && { printf 'unsupported arg
>> %s\n' "$aa" ; continue ; } ; ewal "${a[@]:i+1:${takes[idd]}}" ; (( i +=
>> takes[idd] )) ; done ; } ;   ewal() { eval -- "${cmd[idd]}" ; } ;   parse 1
>> -o 3 4 --opt 6
>> 1yes
>> 2:3
>> 1yes
>> 2:6
>> ~ $
>>
>> On Tue, Sep 7, 2021, 05:58 angioberlinguer <
>> angioberlinguer@protonmail.com> wrote:
>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On Tuesday, September 7, 2021 3:53 AM, Alex fxmbsw7 Ratchev <
>>> fxmbsw7@gmail.com> wrote:
>>>
>>> > yea do so, good luck
>>>
>>> * Do you have a strategy on how to handle multiple values for an
>>> option?  Would be
>>> eager to read through.
>>>
>>> > On Tue, Sep 7, 2021, 05:36 angioberlinguer
>>> angioberlinguer@protonmail.com
>>> > wrote:
>>> >
>>> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> > > On Tuesday, September 7, 2021 3:14 AM, Alex fxmbsw7 Ratchev <
>>> > > fxmbsw7@gmail.com> wrote:
>>> > > well imho such is weak
>>> > > at a standart minimum, a -o or --opt with a one required argument,
>>> needs
>>> > > still to be parsed both ways
>>> > > i mean with space for next arg or a = for inside_this_arg
>>> > > .. not just the --opt variant
>>> > > the code to support this could be simple
>>> > > but i discourage the use of mixed args ( eg with an equal sign
>>> instead of
>>> > > on its own )
>>> > >
>>> > > -   Ok, Alex, I will focus on supporting both.
>>> > >
>>> > > codewise, per !i in args, parse off the part before = whenever
>>> exisiting,
>>> > > and check then if its a supported arg, then check whenever that arg
>>> needs
>>> > > required number of args, then parse em, the first guess being the
>>> part
>>> > > after =, in case
>>> > > like without = an arg can have 3 args, no =, -o 1 2 3 otheropt,
>>> --opt 1 2
>>> > > 3 otheropt
>>> > >
>>> > > -   This is interesting, not thought about having multiple args yet.
>>> > >
>>> > > Will spend some more time on it, and send over my solution, and
>>> discuss
>>> > > how to enhance its capability.
>>> > > On Tue, Sep 7, 2021, 04:55 angioberlinguer
>>> angioberlinguer@protonmail.com
>>> > > wrote:
>>> > >
>>> > > > Hi Alex , thanks fuck for that! It's not a total disaster then.
>>> Have
>>> > > > found some useful discussions
>>> > > > in the following stackoverflow question. They handle short-options
>>> with
>>> > > > spaces and long-options with
>>> > > > equal signs.
>>> > > >
>>> https://stackoverflow.com/questions/192249/how-do-i-parse-command-line-arguments-in-bash/29754866#29754866
>>>
>>>
>>>