<<< Date Index >>>     <<< Thread Index >>>

Re: [Mutt] #3097: mutt's multi-file -a handling fails for



#3097: mutt's multi-file -a handling fails for POSIX-compliant getopt()
---------------------+------------------------------------------------------
  Reporter:  jhawk   |       Owner:  mutt-dev                  
      Type:  defect  |      Status:  new                       
  Priority:  minor   |   Milestone:  1.6                       
 Component:  mutt    |     Version:  1.5.17                    
Resolution:          |    Keywords:  attachment -a posix getopt
---------------------+------------------------------------------------------

Comment(by agriffis):

 Replying to [comment:3 pdmef]:
 > [...] are unsupported (I've never even seen or used that form). If
 argument reordering makes any of these work, this is a "nice to have"
 feature/side effect IMHO, but we shouldn't start supporting it officially.
 When using extensions such as leading - or +, we need to either provide
 solutions for non-GNU-getopt or ship GNU getopt with mutt.

 Regarding unsupported syntax, I agree the second one was contrived and
 unnecessary.  I think the first form is relatively common, though that
 doesn't mean it must be supported.  Regarding my patch, I don't think it's
 necessarily the best solution, but if possible I'd like to avoid the POSIX
 requirement of options before addresses.

 > I don't know what the best practice to handle this type of problem is,
 but how about looking for "--" first, set it to NULL, parse the option
 string before it using getopt() and take the address list behind it?

 I think that makes assumptions about how getopt will consume argv (though
 I was also making similar assumptions in my patch).  I think you'd have to
 pass in a recalculated argc to getopt.  It also assumes that -- can never
 be an optarg.

 Replying to [comment:4 jhawk]:
 > Just to be perfectly clear, using "+" at the start is an instruction to
 GNU getopt to behave like POSIX getopt, and POSIX getopt ignores the "+".
 So using + to force GNU getopt to behave in POSIX form seems the right
 answer for everyone -- it ensures consistent POSIX behavior on GNU and
 non-GNU systems.
 >
 > The forms cited by agriffis are not valid in the synopsis, nor do they
 work on my system. I also don't see the need for anything beyond the
 document forms...

 Sorry, I didn't mean to muddy the water with an alternative patch.  Maybe
 your original patch is best... it's certainly the simplest solution.  I'm
 just not fond of the way it prevents syntax that presently works on Linux.

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3097#comment:5>
Mutt <http://www.mutt.org/>
The Mutt mail user agent