Add long options like --part

[ndim]

Switch from getopt(3) to getopt_long(3) and add a few long options as aliases to existing short options, e.g. "--help" and "--part" being aliases for "-?" and "-p", respectively.

The getopt_long(3) function is available on GNU, BSD, and the existing msvc/getopt.[ch] already implements getopt_long() on Windows. This should cover all systems avrdude supports.

• Use getopt_long(3) instead of getopt(3)
• Add long options from @WestfW Support options like --config --part and --port #1922 (comment)
• Adapt the avrdude usage message shown by "-?" or "--help" to show the new long options.
• Refine, review and finalize the set of new long options
• Adapt the man page to reflect the long options
• Adapt the texi manual to reflect the long options

Closes: #1922

[stefanrueger]

Now that I look at the list carefully, I don't think tty is a good long option name to signify -t for the principal reason that tty describes a communication method (teletype), which is orthogonal to what -t does. Terminal input can come from a file, from a pipe, via a USB connection etc and not necessarily from a tty. I'd prefer to either have no second long option for -t, but if there is an appetite for a second option, I'd much rather have one of --interactive, --console, --avr-console, --shell or similar. We normally use the wording terminal or interactive terminal in the documentation for -t, so --terminal might be sufficient.

Could we add --terminal-command for -T (note capital T), which like -U is not interactive?

[ndim]

"shell" implies turing completeness. "interactive" captures the spirit well.

[stefanrueger]

-n meant originally don't write to the AVR part for -U operations, where -n would write the file to stdout instead of the AVR memory. When other ways to write to the AVR were implemented (-t, -T, ...) there was no way to test these in a dryrun as it were until the -c programmer dryrun was implemented. I now wonder whether --test should be --test-U or rather --test-update to clarify the role of that option.

[stefanrueger]

I still think --test is the wrong mnemonic. Given we have --memory for -U we should rename --test to --test-memory as its scope is confined to -U/--memory operations.

[stefanrueger]

Cool improvement! I like this PR

[MCUdude]

I'm happy with the PR, but I have a few suggestions, based on my personal opinions:

• The -? --help text should print all long options. Right now we're missing --config.
• -O, the oscillator calibration command could have a long option --osccal.
• Maybe use --interactive instead of --tty
• In general, I don't see much need for lots of duplicate long options as long as the long name is descriptive.

[ndim]

I wonder whether -U should even get a direct 1:1 replacement long option.

A set of --read-memory and --verify-memory and --write-memory long opts with suitably adapted arguments could make more sense. And get rid of the colon problems on Windows while the argument is redefined.

I guess --(read|verify|write)-(eeprom|flash) is not flexible enough to accommodate for complex parts' memory layouts?

[MCUdude]

I wonder whether -U should even get a direct 1:1 replacement long option.
A set of --read-memory and --verify-memory and --write-memory long opts with suitably adapted arguments could make more sense. And get rid of the colon problems on Windows while the argument is redefined.

Good idea! But how would we let the user specify the format ( :i, :r, :m etc.)?

-read-memory flash:myfile.hex:i

[ndim]

I wonder whether -U should even get a direct 1:1 replacement long option.
A set of --read-memory and --verify-memory and --write-memory long opts with suitably adapted arguments could make more sense. And get rid of the colon problems on Windows while the argument is redefined.

Good idea! But how would we let the user specify the format ( :i, :r, :m etc.)?

--read-memory flash:myfile.hex:i

There are other characters which can be used as separators. Or --read-memory (i|hex)? flash:c:/foobar/myfile.hex. Or --read-from flash --write-hex myfile.hex. Or --read-from flash --write myfile.hex --format hex. Or something entirely different.

With long options, we are not constrained by the idiosyncrasies of the past.

[stefanrueger]

I guess --(read|verify|write)-(eeprom|flash) is not flexible enough to accommodate for complex parts' memory layouts?

Correct. Avrdude knows three operations, some 48 memories and 12 file formats. Is the suggestion for main.c to entertain some 144 long options for all (op, memory) combos? Or 1728 long options to expand the space to all (op, memory, file format) combos? There is the added difficulty that a new part in a custom config file may well introduce a new memory, which requires new long options to automatically spring up in that case.

Or --read-from flash --write myfile.hex --format hex

Projecting the -U parameter space onto these axes is a neat idea but complicates parsing, which would need to be aware that a list of more than one -U operations can be specified. Given that the format used to be optional (there are defaults depending on r/w/v) which file has the default format and which one the octal format in --read-from flash --write file1.hex --format oct --write file2.hex --read-from eeprom?

And how should the command line express -U sketch, which updates flash from the file sketch?

(i|hex)

That's another pitfall: i signifies Intel Hex files, and h a simple comma-separated ASCII list of hexadecimal numbers in the format 0x.., so hex as a long name for the format can be misleading. As would be binary or bin which could either imply raw data or a list of 0b.... binary numbers.

Also note that allowing a different way than appending :x to the file name for expressing the file format will invariably draw demands on doing that for files in the terminal syntax, too (verify flash sketch:d). So, even simple ideas will require a lot of implementation work.

All of above can be done and done well, but should it? I believe the best thing for now is to have a one-to-one long replacement option for -U and deal with novel ways to express a series of -U memory manipulations in a separate PR that can be independently implemented, critiqued and tested...

[MCUdude]

I think we should wrap it up and merge this PR.
We got long options, and if we can print a small help message if the user got the -U / --memory flag wrong, that could resolve most issues I think. If we also can mention the long options in error messages that mentions short options (like "clock speed too high, use -B 125kHz"), that would be really neat!

[ndim]

Note to self: The usage message should mention e.g. --part and possibly other long options.

[stefanrueger]

It would be great to wrap up this PR.

I support all of @MCUdude's suggestions here.

Suggesting a new syntax for -U using long options or otherwise is probably best suggested in a different PR (as it's complex and can have a few uninteded ramifications as above discussion shows).

Over to you, @ndim to continue the great work here!

[MCUdude]

@ndim sorry for pushing directly to your branch. I was trying to push to my own fork or your development branch, but I messed up somewhere on the way. If you look at the last commit, what I did was to add a few missing long opts to the help text, and remove duplicate log opts.

[MCUdude]

I think the implementation itself is OK now. I've done the manpage documentation but still have the texinfo docs left.

[MCUdude]

@stefanrueger I think this PR is mostly done now, so please review! The only longopt name I'm not so sure about is --test. Is this really the most accurate substitute for -n?

@ndim sorry for the noise. The reason why I messed up/couldn't fork your branch is because I already have a fork of the Avrdude project. And I misunderstood and accidentally pushed straight to your fork instead of to a "fork of your fork". But at least now the docs should be OK, and the missing longest names in the help text is now present.