Norm wrote: > David Levine <levin...@acm.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@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers