[Top][All Lists]

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

Re: [Nmh-workers] The invisible mail folder

From: Robert Elz
Subject: Re: [Nmh-workers] The invisible mail folder
Date: Wed, 28 Feb 2007 12:29:32 +0700

    Date:        Tue, 27 Feb 2007 17:01:12 -0600
    From:        Neil W Rickert <address@hidden>
    Message-ID:  <address@hidden>

  | The notation "+folder" for identifying a mail folder goes back at
  | least to ucbmail (/usr/ucb/Mail  or /usr/ucb/mail or emulated by
  | mailx).

I wouldn't presume that ucbmail is older than mh - as I recall it,
they have a similar age, both were developed because of just how pathetic
the 6th edition unix mail command was.   Which of the two of them first
picked '+' as a folder indicator, and was copied by the other I certainly
would not guess, it's also possible (if perhaps a little unlikely) that
they both adopted it independently.   I'd not be surprised to learn that
ucbmail picked up this syntax from mh (or perhaps they both adopted it
from something older - from some other OS).

To the topic, I personally don't care what +. and +.. are defined
to mean, I'd prefer to avoid any kind of special case, or at least
too much of a special case, but as long as they have a defined meaning,
what it is doesn't really matter (I also doubt that almost anyone ever
uses them).

I do however want to keep the bare '+' to mean the top of the local
folder tree - certainly in the mhpath command (I use mhpath + very
frequently indeed - that's how to find the home of the components
files, and all the other templates, and alias files).   Then, if
mhpath is going to use '+' that way, for consistency, so does everything

I don't care that some sh constructs get a little harder to use, because
sh doesn't (by default anyway) understand what the '+' is implying.
There are easy workarounds for this which work just fine (and in any case
some kind of workaround is essential, as normally the shell handles all
relative paths wrt its current directory, where for MH we want them
handled either relative to the folder root, or the current folder, and
never relative to the process's current directory).

I would also never pick the --word=thing syntax for anything, certainly
it is more general (too general) but it is way too verbose to actually
use on the command line by humans (for use in scripts or other places
none of this really matters, and any syntax is OK).


reply via email to

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