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

Re: length of path variables



Hi Bertrand,

On Tue, Nov 30, 2010 at 12:42:44PM +0100, Bertrand Yvain wrote:
> mutt should use PATH_MAX instead of _POSIX_PATH_MAX, this would allow to
> push the boundary to the actuel limit of your system.

yes, I also thought so! But of course that would lead to path-type
variables of length 4096 on many systems, causing another imbalance
with string-type variables. Is there a reason why mutt uses
_POSIX_PATH_MAX (besides historical ones)?

> As a work-around, I would suggest to set editor="vim -S lengthy/script"
> instead of putting the script body on the commande line.

The problem is that the vim-scripts are automatically generated and are
each different. I patched mutt as a work-around (for me) :-).

> > 1. Add a new variable type "command"
> > This would make sense, since lots of variables are not really path names
> > (although they usually contain one at the beginning), but commands that
> > are handed over to system(3) and do not obey any maximum file path limit
> > anyway. Currently, all those variables ($display_filter, $editor, ...)
> > are expanded using mutt_expand_path(), which does not make much sense
> > besides the tilde [~] for HOME (who uses $spoolfile at the beginning of
> > $editor?), so this could lead to a cleaner handling.
> 
> Indeed, a command is not a path.  I would favor this configuration
> variable type.  However, I see no reason to omit path expansion.

Of course path expansion could still be performed (maybe it is good for
backwards-compatibility). But I can't imagine a realistic scenario where
it would be useful :-) (maybe one editor per mailbox: editor="^/editor")


Greetings,
Johannes

Attachment: pgpaKtvCh3QoJ.pgp
Description: PGP signature