Discussion on Options and Parameters in Proxmark Commands

[pwpiwi]

@iceman1001 wrote in #465:

Pretty soon the discussion of a unified parameter is needed, since you seem to be fond of the prefix "-"
while we have spend time not using it. I don't mind either, but I prefer that we have one and not three like >we have to day.

no prefixed inparameters.
letter only prefixed parameters
"-" + letter prefixed parameters.
Same goes for inputed "hex".. Either "405060" or "40 50 60" or both accepted.

This is indeed a topic I wanted to discuss ages ago. The proxmark way of handling parameters and options is neither consistent nor common practice. We are all used to options like -h and an alternative long version like --help for any Unix or Windows program. Why don't we adopt this common practice and start using getopt() (or its sister getopt_long()) as in client\loclass\main.c and client\reveng\cli.c? This is not only common practice but also avoids those ugly command line parsing we have in many places.

[iceman1001]

I welcome this.

LUA script also uses "-" + letter prefix
All different command line parsing is ineffective.

I just one way, not three. And in a standard way so its easy for new contributors to add. Not to worry or spend time in "how to parse commandline in proxmark".

[marshmellow42]

i'm for it. ( though i will have to learn how getopt() works.. ;) )

[iceman1001]

yeah, getopt() crash-course needed for me too.

[pwpiwi]

https://www.gnu.org/software/libc/manual/html_node/Getopt.html#Getopt

[iceman1001]

Actually, all blogs, forum posts will be upset but I still want it to be unified.

[iceman1001]

...well... piwi... will you start the unifying with one getopt? The loclass, reveng has their own, we would need to have one.

[merlokk]

So, it needs to use getopt_long?

and this?
"-" + letter prefixed parameters. (dont know... lets think)
Same goes for imputed "hex".. "405060" and "40 50 60" accepted. (it will be cool because some strings in the internet with spaces, some without.... just for more convenient copy-paste)

[iceman1001]

getopt_long, whats the difference?

if we have [-h] , which could be confusing between being in the shell vs inside pm3 client.. What you think?

Agreed, hex input both kinds, with/ wo spaces, would increase usability.

[merlokk]

I don't know what the difference between getopt libs. Ill look.
We need functionality like:

bool SelectField = OptionExists("s");
GetOptionParam("a", APDU, &APDUlen);
GetLastParam(APDU, &APDUlen);

[merlokk]

I have time to investigate at first part of next week. If someone can do earlier, please, do)

[iceman1001]

I'm guessing,

getopt ==  "-h"
getopt_long ==  "--help"

[merlokk]

https://github.com/skeeto/optparse
https://github.com/cofyc/argparse

need too look - maybe there is cool parser on github)

[pwpiwi]

skeeto makes some good points in his README.md (https://github.com/skeeto/optparse/blob/master/README.me) which discourage the usage of the original getopt(). cofyc prevents the same drawbacks and adds error message handling. Both licenses are compatible with GPL v2.

+1 for cofyc/argparse

[merlokk]

OK,
updated list)
https://github.com/skeeto/optparse
https://github.com/cofyc/argparse
https://github.com/hroptatyr/yuck (need to look deeper)
https://github.com/argtable/argtable3 (i like it, but it needs to look)
https://github.com/jpommerening/choice - this simple with config from struct

[merlokk]

and all of them dont have initialization from char*, just from argc argv

[pwpiwi]

Yes, a function to split the line into options and parameters is required in all cases. It would be an additipnal task of this function to distinguish a hex parameter with spaces from multiple parameters.

[merlokk]

If we have - at the parameter's beginning - all is ok, this function can be written easily)
If not - needs to think.

guys, what are you thinking about parameters: - or without?

[pwpiwi]

I am for the standard: - or -- for options. = or nothing for parameters. Nothing for additional arguments.

HF 14a raw -c -t 10 60 01

HF 14a raw : command
-c : option
-t: option with mandatory parameter
10: parameter
60 01 : arguments

[merlokk]

and HF 14a raw -ct 10 60 01 too ?

[merlokk]

I look at https://github.com/argtable/argtable3
and see that it may be what we need:

    struct arg_lit *n     = arg_lit0("n", NULL,         "do not output the trailing newline");
    struct arg_lit *e     = arg_lit0("e", NULL,         "enable interpretation of the backslash-escaped characters listed below");
    struct arg_lit *E     = arg_lit0("E", NULL,         "disable interpretation of those sequences in <string>s");
    struct arg_lit *help  = arg_lit0(NULL,"help",       "print this help and exit");
    struct arg_str *strs  = arg_strn(NULL,NULL,"STRING",0,argc+2,NULL);
    struct arg_end *end   = arg_end(20);
    void* argtable[] = {n,e,E,help,vers,strs,end};

I will try to implement one command
OK?

[pwpiwi]

Looks great. Has a good tutorial as well: http://www.argtable.org/tutorial/

I propose to start with hf 14a raw. It should be possible to refactor it without changing the syntax.

[merlokk]

OK, i will try and show PR) lets look...

[merlokk]

OK. lets think, test and merge.

especially needs to check if reveng part still works OK.

[merlokk]

can be closed