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 pdmef):
Replying to [comment:5 agriffis]:
> Replying to [comment:3 pdmef]:
> > 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.
I think the latter assumption (made by the current code already) has to be
made when using getopt. If not, I think we need to roll our own (partial)
option parsing as -- actually only has a special meaning following an -a
option. Given something like
{{{
mutt ... -s -- addr1 addr2
}}}
means a subject of "--" and addr1+addr2 (i.e. -- not special) as
recipients while in
{{{
mutt -s foo -a file1 file2 -- addr1 addr2
}}}
it is special.
Regardless of what patch makes it into the tree, I think we need another
one fixing the code to only accept -- after an -a argument.
Attached is a patch that reverse-looks for --, adjusts argc and passes the
shortened argv to getopt. It can then simply parse all non-option
arguments as files and takes all arguments in argv tail after -- as
recipients.
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3097#comment:6>
Mutt <http://www.mutt.org/>
The Mutt mail user agent