Norm wrote:
David Levine <levinedl(_at_)acm(_dot_)org> writes:
Norm wrote:
I don't know that whatnow's attach ever gave me a blank
Nmh-Attachment header. What you are probably referring to
was my request that send silently remove any such
headers. I asked for that so that users could put them in
their templates to be filled in, or left blank at
composition time.
I just committed the fix for that, but only in send(1).
post(8) is coming.
Also:
Added check in send(1) of attach (default Nmh-Attachment)
headers to ensure that only plain files are attached.
Otherwise, it is a fatal error. Note that whatnow's
attach will continue to allow attachment of directories
because it expands those out to their contents. It
doesn't check what the contents are, though. That's why
we needed to add this check.
It does the right thing with symlinks, as long as they
dereference to plain files.
It seems to me that, ideally, attach should never attach anything
that send would reject as an error. Is this too unreasonable a
requirement?
If you're talking about a new, standalone attach, that sounds
reasonable. But I think that we should leave the checks in,
anyway.
I added this check to post:
Filter out all Nmh-* headers in post(8). Do that
silently for empty ones (no header body), and warn about
non-empty ones.
If you accept that requirement then, given the above about send, I
suggest
that:
attach should reject with, an error message, any:
Unreadable files (including directories)
Dangling symbolic links
Symbolic links to unreadable files (including unreadable
directories)
Directories or symbolic links to directories, unless the -r option
is given
Note that the current "attach -r" is an undocumented relic of the
implementation, because whatnow passes the -r to ls. Maybe it
shouldn't even be allowed. The whatnow documentation specifically
says "attach files".
Even though attach should check symbolic links, it should attach a
symbolic link to an ordinary file as the link itself. (This would
allow the link to have a different suffix then the file linked
to). That's what it does now.
Are you sure about that? When I attach a symbolic link
to a plain file, it attaches the file, not the link.
I think that's much more useful than trying to send a MIME
symlink. And I'm not sure how portable that would be.
inode/symlink is out there but IANA doesn't list an inode
content type.
If the -r option is given then attach should recursively
attach all files (including files whose names begin with
'.' ?) in any directories encountered.
Since a simple error, could inadvertently generate hundred of
attachments, maybe attach should return with the number of files
attached, when the -r option is given, or perhaps always, for
consistency.
I'm not sure what we could do with that return value. And
if you're talking about a large value, I likely wouldn't
notice the difference between two large values.
And if there's an error, I'd like it to just fail so I
could fix it.
Maybe requiring attach to not make send unhappy is overkill, and is
not worth the extra trouble?
I don't think it's worth the (my) trouble to try and add/
subtract these to/from whatnow's attach.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers