Hello Ralph, all. Ralph Corderoy wrote in <20181214095544.6099521...@orac.inputplus.co.uk>: |>> -R | -R address |>> Without any argument any folders will be opened read-only. |>> With argument an reply-to adress is specifed on command line. |>> Only the first argument after the -R flag is used as the |>> address. |> |> -R flag. This now really works, btw. We do not support optional |> arguments, and Heirloom did not too. This must be some other |> getopt implementation that is used. | |Some getopt(3) support `::' to mean an optional argument.
Yeah, well.. |Another alternative to try with your existing implementation is using |`:' for a mandatory argument and decrementing `optind' if the `argument' |looks like an option. Problem, problem. There is behaviour out there which surprises me and which i dislike, which even made it into the standard, i think there is a -y somewhere around in sccs land which falls into this, you need to say (iirc) -y'bla bla bla', if you say "-y 'bla bla'" you lost. And _we_ do support things like -RfSnoheader, for example, in fact i personally compress options as much as i can, at least on the command line. How should i interpret the above, the behaviour must remain the same. Thus we could only accept "-fR not-an-option", but not and never "-fRnot-an-option". Because checking whether the first byte of "not-an-option" is not an option is not an option. So is not an option is not an option, but .. there is no option? Even then, we could run into trouble for things like "s-nail -fR e...@m.ple": the knowledge that in this case the address _must_ be an argument to -R, because otherwise the command line would make no sense (-R meaning "read-only" is invalid in the "send-mode" which is triggered by the given receiver address) is clearly beyond the scope of a/the command line parser. And, while a weak argument, mail addresses (names) could start with a hyphen-minus. It is true that using -Sreply_to differs from Werner's patch in that that adds upon an address list (iirc) just like -b and -c do, whereas -S sets the variable (which will be splitted) as such. But -R ... ? I also note that the patch is very, very old, and from my usual day-by-day experience is see that reply-to: gets used pretty rarely, but especially so with multiple addresses therein. I had to look whether i would find just one mail in my archive which does that, unfortunately doing so is not easy an easy thing to do with this MUA at the moment. And: pffffh... Finally "::" is impossible for us, as ":" is a regular option, too. But this is the least problem. I am some what opposed to optional arguments it seems. I have a C++ class GetOpt which will be ported and which also does not offer them, not even for long options. So. I have no real idea on -R with optional argument. It possibly would make sense to offer a command line option multiplexer to add to specific receiver lists, for example -T to=f...@to.ple -T bcc=f...@bcc.ple -T reply-to=f...@replyto.ple Because. The standard options parse arguments as lists of addresses, whereis here we could define that the argument is one and exactly _one_ addressee (just like with Fcc: headers), which would be a real improvement. But that does not help Werner and his -R, of course. But i keep this idea. Ciao. P.S.: now that SUSE appeared on the list i thought i will release v14.9.12 on 2019-01-11, which will be my personal 20 year of UNIX anniversary. It was a SUSE (SuSE back then) with enabled debug symbols and caused a lot of zombie processes, and this was very frightening. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
