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]

--memory is a good long option name b/c it puts the focus correctly: the operations r, w and v all refer to memory and, crucially, not the corresponding file; originally -U got its name from the generic update operations it might describe, so I would also allow the mnemonic --update or, alternatively, --update-memory. I have an ever so slight preference for the latter: personally, I think long options are good in shell scripts to improve readability, so I am less worried about the length of long options. If we go with the latter, we wouldn't need --memory.

[MCUdude]

I would argue that --memory would be sufficient. The help test will get awfully long if we have tons of long options that to the same thing. And the -U flag doesn't necessary updates the memory.

IMO, --memory flash:r:myfile.hex makes way more sense than --update-memory flash:r:myfile.hex.

[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]

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...