Re: [bug-mailutils] pick missing the "--" feature for matching arbitrary components

[Sergey Poznyakoff]

Hi Joe,

> >   refile `pick +inbox \
> >         -from           address@hidden \
> >     -or -to             address@hidden \
> >     -or --apparently-to address@hidden \
> >   ` +BALUG
> >
> > The Gnu utils version of pick does not seem to know what to
> > make of something like "--apparently-to", it gives me the
> > error:
> >
> >   pick: unrecognized option `--apparently-to'
> >

Yes, it conflicts with the normal long options handling (long
options are those beginning with double-dash) and therefore is
disabled by default.  It is suggested to use `-component apparently-to' or
`--component apparently-to' instead of `--apparently-to'.  In
both cases, you can abbreviate `--component': e.g. `--comp
apparently-to' will do as well.

> At long last I have access to the mailutils info (I built it from
> scratch, just to get this...

FWIW, there is online copy of it at 
http://www.gnu.org/software/mailutils/manual.

> mailutils packages for some reason), and I see that this is called
> a "non-standard extension" (there are standards for mh?) and is
> considered deprecated.

The words "non-standard" refer to GNU standards, not MH ones.  All GNU
utilities support so-called "long options", which are introduced by
a double-dash sign.  The GNU standards say that if the program encounters
an unrecognized option (roughly, the one that is not listed in `program
--help' output), it must issue a meaningful diagnostic message on
the stderr.  The problem with the MH notation of component matching is
that it allows the `--' to be followed by arbitrary string, so that
there is no way to discern between an unrecognized or erroneous option
and a header matching request.

> However:
> 
>   It is recognized only if 'pick' is called from within another
>   program, so that existing application continue to work.
>
> And that is indeed what I'm doing, calling pick from within an
> already existing shell script.

Perhaps the docs don't explain that well.  Technically, the old
way of specifying header matching requests is turned on when pick
sees that its standard input is closed.  This method allows it to
interact well with the MH-E system, but is not able to catch all
possible uses of pick.  Admittedly, it is rather kludgy so any
ideas on how to do it better are quite welcome.

Presently, your command will work if you reword is as (assuming Bourne
shell):

   refile `pick +inbox \
         -from           address@hidden \
     -or -to             address@hidden \
     -or --apparently-to address@hidden <&- \
   ` +BALUG

Note the `<&-', which closes the stdin.

Regards,
Sergey