bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems with "mail", maildir -> renamed to mailspool


From: Sam Roberts
Subject: Re: problems with "mail", maildir -> renamed to mailspool
Date: Wed, 27 Mar 2002 21:39:11 -0500
User-agent: Mutt/1.3.16i

Quoteing address@hidden, on Wed, Mar 27, 2002 at 11:24:41PM +0200:
> > There's also Debian Bug#139678, which says that the -m long option name
> > "--maildir", is confusing. I agree. I wish the option was called
> > --mailspool or --spooldir or whatever, so it doens't clash with the
> > Maildir format.
> > 
> 
> Agreed. This is quite reasonable.

Sergey:

I'm hacking mu_argp.c right now, adding mailer and locking options,
so I'll change this. It won't make it in for a week, though, likely.

And is:

-m,--mail-spool=URL

OK?

It seems we have a lot of "=" delimited options in the utilities.

> > If I use the -f switch, it completely ignores it:
> > 65563:address@hidden:~$ mail -f /var/mail/jordi
> 
> This is a very frequent mistake, unfortunately. In mailutils' mail
> an argument to --file (-f) is optional, therefore it must follow
> -f option without intervening whitespace. Similarly, if the long
> form is used, its argument must be preceeded by an equal sign
> (again, no intervening whitespace). So, the right form of invocation
> will be either
> 
>      mail -f/var/mail/jordi
> 
> or
> 
>      mail --file=/var/mail/jordi

This is standard behaviour for optional params with GNU long options,
but it bit me, too. Maybe it would be better to make it not optional,
and make a shortcut for ~/mbox, rather than be answering questions all
the time?

Mutt uses:

  >  for the location where mail is saved after being read, default is
     ~/mbox
  <  for where copies of sent mail are saved, if they are, I can't remember
     if there is a default


Or maybe a different option:

   -F, --mbox        Use the saved mail location (default ~/mbox).


Or, I we can add to the standard blurb:

    Optional arguments to short options MUST NOT have any spaces between the
    switch and the option, and mandatory or optional arguments to long
    options are also mandatory or optional for any corresponding short
    options.

 (But this wouldn't help debian, they have GNUs libc, with argp).

Or we could wait to see if we get a flood of complaints, and if we
don't, not worry about it.

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)


Index: argp-help.c
===================================================================
RCS file: /cvsroot/mailutils/mailutils/lib/argp-help.c,v
retrieving revision 1.1
diff -u -r1.1 argp-help.c
--- argp-help.c 13 Mar 2002 09:02:45 -0000      1.1
+++ argp-help.c 28 Mar 2002 02:38:53 -0000
@@ -1194,8 +1194,9 @@
   if (hhstate.suppressed_dup_arg && uparams.dup_args_note)
     {
       const char *tstr = dgettext (state->root_argp->argp_domain, "\
-Mandatory or optional arguments to long options are also mandatory or \
-optional for any corresponding short options.");
+Optional arguments to short options MUST NOT have any spaces between \
+the switch and the option, and mandatory or optional arguments to long \
+options are also mandatory or optional for any corresponding short options.");
       const char *fstr = filter_doc (tstr, ARGP_KEY_HELP_DUP_ARGS_NOTE,
                                     state ? state->root_argp : 0, state);
       if (fstr && *fstr)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]