Re: [Nmh-workers] The attach feature
Ken Hornstein writes: >>Maybe there shouldn't be a separate attach man page, but that doesn't >>seem like a compelling reason, It just says that it shouldn't be in >>man/man1 but possibly man/man7, See man 7 intro. > >Okay, I could see that. Maybe we really need a man page which spells out >all of the various MIME stuff in nmh, and attach could be part of that. >I was also reminded of mh-chart.1, and that's not a command so clearly >the rule about pages in .1 only being commands is not hard and fast. > >>Granted that what goes on under the hood (relationship of attach to send etc.) >>needs documentation, there ought to be documentation for the user-clod like >>me, >>who sees the attach facility as a separate entity. It should include such >>things >>as: (these are examples) >>[...] > >It sounds like you know exactly what needs written. So ... want to write >it? You don't have to know anything about git; I'll gladly take care >of that part. I'll even do my best to convert plain text to *roff if >you want me to (I can't claim to be the best at *roff, but I can do okay). OK, I will have a go at it. But some of what I write will be questions. And many of the answers may well be wrong, to be corrected by my betters. Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] somewhat OT: re procmail or ??
On Tue, Sep 11, 2012 at 2:10 PM, rader wrote: > LOGABSTRACT=yes with procmail-3.22-17 (RHEL/SL) only gets me Subject and > Folder. Is there a new version around I didn't find?? (I only glanced > and saw "3.22" and a msg to "the" ML bounced.) You are right. You have the "From" line added by the delivery agent that includes delivery date and what appears to be the envelope sender, so it is not the "From:" value of the message itself. > > I think for anything else, you will need to write a recipe to call a > > script that can log whatever headers you want to a custom log file. > > I was thinking of patching procmail directly so LOGABSTRACT=yes logs > Date/From/To/cc/Subject header lines. Kinda thinking other prehistoric > creatures might also like that? Possibly, and likely the only convenient way if you want such information associated with the destination folder listed in the log. You can likely achieve a similar affect with recipies, but it would complicate your procmailrc. Looks like there is a users' list for procmail, that still gets some light traffic: http://mailman.rwth-aachen.de/mailman/listinfo/procmail Might want to ping it to see what others think. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] somewhat OT: re procmail or ??
> > I mean, is there something better? > > If not, does anyone have patches for logging e.g. date, from, to? > > Setting LOGABSTRACT=yes in your procmailrc will give you received date, > subject, and from in the log. You can also enable verbose logging, but > unsure if that will give you what you want (or it will give you too > much). LOGABSTRACT=yes with procmail-3.22-17 (RHEL/SL) only gets me Subject and Folder. Is there a new version around I didn't find?? (I only glanced and saw "3.22" and a msg to "the" ML bounced.) > I think for anything else, you will need to write a recipe to call a > script that can log whatever headers you want to a custom log file. I was thinking of patching procmail directly so LOGABSTRACT=yes logs Date/From/To/cc/Subject header lines. Kinda thinking other prehistoric creatures might also like that? steve -- ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] somewhat OT: re procmail or ??
On Tue, Sep 11, 2012 at 1:05 PM, rader wrote: > Am I dinosaur for still using procmail?? Yes, like the rest of us. But I use procmail for mail filtering on my web-based archives. > I mean, is there something better? > If not, does anyone have patches for logging e.g. date, from, to? Setting LOGABSTRACT=yes in your procmailrc will give you received date, subject, and from in the log. You can also enable verbose logging, but unsure if that will give you what you want (or it will give you too much). I think for anything else, you will need to write a recipe to call a script that can log whatever headers you want to a custom log file. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When send does not recognize a mime type
Jon wrote: > It would not be terribly hard to have nmh read this file > on attach or read it on nmh-install. I think we're better off with what we currently have, primarily so that every nmh installation behaves consistently regardless of underlying platform. If a user has a need beyond what's in mhn.defaults, they can add it to their profile. If it's general, let's add it to mhn.defaults so that all nmh users can benefit. > Bottom line, how big of an issue is all this? It isn't an > issue to me at all. I agree. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] somewhat OT: re procmail or ??
Am I dinosaur for still using procmail?? I mean, is there something better? If not, does anyone have patches for logging e.g. date, from, to? OMG, it just occurred to me: maybe it's INFERIOR to slocal these days!?!? :) steve -- ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When send does not recognize a mime type
Ken Hornstein writes: > We (by "we" I mean Steve Rader) did a one-time import; it's not > done every build (for one, not all systems have /etc/mime.types). It would not be terribly hard to have nmh read this file on attach or read it on nmh-install. > >There is also the issue that if types are not in the profile we can > >send 'em but not receive 'em. > > I'm not sure I follow; if we don't know about a type, we just treat it as > application/octet-stream, right? Yeah, I was thinking of automatically spawning a reader application. Bottom line, how big of an issue is all this? It isn't an issue to me at all. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When send does not recognize a mime type
>BUT, finding the file type does not give you the mime type. There's the rub. Well, more versions of file are supporting the "--mime-type" argument. But I'm not loving the idea of importing all of a "file" implementation into nmh; that's just me. Maybe an autoconf test to see if the --mime-type argument is supported? But should that override file extensions? Sigh; not great answers. >I guess that I think that this is pretty much a non-issue. I believe (I didn't >do this part of the work) that we import /etc/mime.types, so we likely have the >mime types for all of the file types that file would recognize. We (by "we" I mean Steve Rader) did a one-time import; it's not done every build (for one, not all systems have /etc/mime.types). >There is also the issue that if types are not in the profile we can >send 'em but not receive 'em. I'm not sure I follow; if we don't know about a type, we just treat it as application/octet-stream, right? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The attach feature
>Maybe there shouldn't be a separate attach man page, but that doesn't >seem like a compelling reason, It just says that it shouldn't be in >man/man1 but possibly man/man7, See man 7 intro. Okay, I could see that. Maybe we really need a man page which spells out all of the various MIME stuff in nmh, and attach could be part of that. I was also reminded of mh-chart.1, and that's not a command so clearly the rule about pages in .1 only being commands is not hard and fast. >Granted that what goes on under the hood (relationship of attach to send etc.) >needs documentation, there ought to be documentation for the user-clod like me, >who sees the attach facility as a separate entity. It should include such >things >as: (these are examples) >[...] It sounds like you know exactly what needs written. So ... want to write it? You don't have to know anything about git; I'll gladly take care of that part. I'll even do my best to convert plain text to *roff if you want me to (I can't claim to be the best at *roff, but I can do okay). >Very naive, stupid question: Why wasn't attach implemented as a shell level >command. Don't need to know, just curious. I think Jon answered that question, but it occurs to me that attach could have been implemented as a shell command and the functionality could have been linked into whatnow just like we do with "send" today. But that would have been more work; I understand why that wasn't done. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When send does not recognize a mime type
On 2012-09-11, at 7:59 AM, n...@dad.org wrote: > I guess I kinda believe the opposite. For example send won't send a message > if it > doesn't understand any of the addressees. I think that's a good thing. The > general philosophy of mh was (contrary to the UNIX philosophy) that if > anything > is wrong do nothing. Not knowing a file's MIME type is not an error. It can't be, since not every type of data has a specific MIME type. E.g., what is foo.dot? foo.xyz? cat.8? These are all files that exist on my systems. foo.dot and foo.xyz are text files. The suffixes are local differentiators with meaning only to me. Adding the dot and xyz suffixes to mimetypes with a text/plain attribute is wrong, since another .xyz file might contain, say, sample raw data from a random number generator. I.e. there is no recognized conventional type for .xyz files. This is why MIME has fallback rules: text/plain for printable ASCII text content, and application/octet-stream for everything else. What about cat.8? On my UNIX systems, that's a pre-formatted man page (text/plain). On my Plan 9 systems, it's object code from the 80386 compilers. (Ditto for cat.2, which could be a pre-formatted man page for a system call, or object code from the 68020 compilers.) This is why deriving the MIME type from the file name is fatally flawed. It's not MIME's job to fix your typing mistakes. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
> From: Lyndon Nerenberg > > > On 2012-09-11, at 7:45 AM, Michael Richardson wrote: > > > yeah, but can we not use ()? They really suck if you actually have to > > \(-type them rather than shell complete them. > > (And if you have fu.gif and fu(, you have to type the (...) > > Parens can cause problems with shell globbing as well, and should be > avoided. I > prefer: > > foo-> foo-1 || foo-2 || foo-3 ... foo-999 etc. > foo.bar-> foo-1.bar > foo.bar.baz-> foo.bar-1.baz > > If foo-1 is an existing valid file you get foo-2 instead of foo-1-1, but > it's a rare > enough occurrence that it's not worth worrying about. Sounds good, better then parens, to me. steve -- ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When send does not recognize a mime type
Lyndon Nerenberg writes: > What we really ought to do is derive the MIME type from the file contents. > I realize this means bundling an implementation of magic, but I think it's > worth the price. There are several license-compatible implementations out > there that could be used as a starting point. Send runs the file command on files. However, it only does this to get additional descriptive information. Send (in make_mime_composition_file) tests for the existence of a known suffix, and then picks text/plain or application/octet-stream depending on whether or not there are non-ASCII characters in the content (see earlier complaints). It could be changed to run file if there was no known suffix. BUT, finding the file type does not give you the mime type. There's the rub. I guess that I think that this is pretty much a non-issue. I believe (I didn't do this part of the work) that we import /etc/mime.types, so we likely have the mime types for all of the file types that file would recognize. There is also the issue that if types are not in the profile we can send 'em but not receive 'em. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
On 2012-09-11, at 7:45 AM, Michael Richardson wrote: > yeah, but can we not use ()? They really suck if you actually have to > \(-type them rather than shell complete them. > (And if you have fu.gif and fu(, you have to type the (...) Parens can cause problems with shell globbing as well, and should be avoided. I prefer: foo -> foo-1 || foo-2 || foo-3 ... foo-999 etc. foo.bar -> foo-1.bar foo.bar.baz -> foo.bar-1.baz If foo-1 is an existing valid file you get foo-2 instead of foo-1-1, but it's a rare enough occurrence that it's not worth worrying about. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When send does not recognize a mime type
On 2012-09-11, at 6:13 AM, David Levine wrote: > What to do with a file without an extension (.) in > its name? Or not consider that an error? What we really ought to do is derive the MIME type from the file contents. I realize this means bundling an implementation of magic, but I think it's worth the price. There are several license-compatible implementations out there that could be used as a starting point. As for outright failure for unrecognized types, this really violates POLA. If something is labeled application/octet-stream, at worst it means the content might not receive some automated processing by the receiving client. While annoying, perhaps, it's far from fatal. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The attach feature
n...@dad.org writes: > Instead of saying what information should be in what man pages, and what man > pages should exist, let me opine a desideratum: > > Granted that what goes on under the hood (relationship of attach to send etc.) > needs documentation, there ought to be documentation for the user-clod like > me, > who sees the attach facility as a separate entity. It should include such > things > as: (these are examples) > > The syntax of attach: multiple files, escapes etc. (David, isn't this > already more than one paragraph?) > > Recipients will only see base names of the arguments to attach > > Extension names are case insensitive. > > What happens if a file has an unrecognized extension > > ... > > All of this might be obvious to you, but it wasn't to me. And a lot of it > probably still isn't. > > Lest my griping mask my pleasure with the attach facility, let me make it > clear > that I'm delighted by it. > > Very naive, stupid question: Why wasn't attach implemented as a shell level > command. Don't need to know, just curious. > > Norman Shapiro Attach was "implemented as part of whatnow" because that seemed to be the place to put it for one who uses comp/repl/forw/etc. like I do and I implemented it. It couldn't be done as a shell command combined with the above because that would have meant you'd have to leave the editor, suspend whatnow, run an attach command, resume whatnow, and then send. Cumbersome to say the least. But, the reason for the quotes above is that attach is really implemented as part of send. I went to great pains to make it something that would work given the separate-shell-command nature of nmh. That's why attachments are listed in "magic" headers. One of the nice things about this is that YOU can implement attach as a separate command if you want to; would take less that 5 lines of shell script. The ability do do stuff like this is a main reason why I use nmh. I do agree that there is some difficulty in figuring out the appropriate place for extensive documentation on attach. That's because the work is done using mhbuild by send when an attachment header is present whether or not it was added by whatnow. It might make sense to have a detailed description somewhere and reference it from other places. I think that to make things clear any description should reference the appropriate RFCs; there are things here that you imply were nmh decisions whereas nmh is just implementing the RFCs. Now, on to the part that always gets me into trouble. Norm, you've had a lot of questions about things that are not obvious to you. My experience is that if you have these questions many other folks who are two shy to ask have 'em to. So please take the knowledge that you've extracted from all of the responses and make the manual pages better. Time to step up! Propose something, get no responses, implement it, and then field the complaints :) Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When send does not recognize a mime type
Ken Hornstein writes: > >I guess I kinda believe the opposite. For example send won't send a > >message if it doesn't understand any of the addressees. I think that's > >a good thing. The general philosophy of mh was (contrary to the UNIX > >philosophy) that if anything is wrong do nothing. For various reasons > >some commands (for example, sortm -- with good reason) ,violate that > >rule, but at least it's a goal. > > Here's my problem with that ... is an "unknown" file suffix "something > wrong"? Or does it really mean "send as generic binary data"? > Everybody should be able to at least save application/octet-stream > to their local filesystem and can then do whatever they want with > it. Also, I'm wondering what other mail programs do when they're > asked to send MIME content with an unrecognized file extension; it > might be worthwhile to understand what the expected behavior is here. > > --Ken I agree with Ken here. There is nothing wrong with unknown file types. That's covered by the RFCs. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The attach feature
Ken Hornstein writes: >>I don't remember all the places I looked and things I tried, nor do I >>remember the order in which I did them. But here are some of the things I >>tried: >> >> man attach >> man -k attach >> man whatnow (It told me the feature existed, but not much more) >> man nmh (to see if there was a relevant man page) >> man send (lots of hits for "attach" but nothing about the attach >> command) > >So I guess this is partially the fault of the way nmh works; whatnow does >some things (and implements the "attach" command) but the real mechanics >are handled by "send". Sure, once you KNOW that what attach does is add >a special header, the information in the send man page makes more sense. > >>In my humble (but correct :-) opinion there should be an attach >>man page. It would, at the very least give the basic idea, (attach >>generates certain headers which send understands), the syntax of the >>command, and pointers to other man pages. > >See, I'm not so sure about that. It's not a new command that happens >at the shell prompt; Maybe there shouldn't be a separate attach man page, but that doesn't seem like a compelling reason, It just says that it shouldn't be in man/man1 but possibly man/man7, See man 7 intro. Instead of saying what information should be in what man pages, and what man pages should exist, let me opine a desideratum: Granted that what goes on under the hood (relationship of attach to send etc.) needs documentation, there ought to be documentation for the user-clod like me, who sees the attach facility as a separate entity. It should include such things as: (these are examples) The syntax of attach: multiple files, escapes etc. (David, isn't this already more than one paragraph?) Recipients will only see base names of the arguments to attach Extension names are case insensitive. What happens if a file has an unrecognized extension ... All of this might be obvious to you, but it wasn't to me. And a lot of it probably still isn't. Lest my griping mask my pleasure with the attach facility, let me make it clear that I'm delighted by it. Very naive, stupid question: Why wasn't attach implemented as a shell level command. Don't need to know, just curious. Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When send does not recognize a mime type
Norm wrote: > ls ~/Graphs/name* > > to get > > /home/norm/Graphs/name.jqg > > which I pick up with my mouse to insert into the what now attach > command. Off topic, but you can do tat from within whatnow and potentially avoid some errors: What now? ls ~/Graphs/name* [ls output shown here, which you could grab with the mouse, or see below about readline] What now? a ~/Graphs/name.jpg What now? al name.jpg (al)ist gives me the chance to see what I've attached before sending. I'm in the habit of always doing that, esp. because I do things like: a ~/Graphs/n*.jpg When nmh is configured with readline, which is very likely on Fedora: At that second What now? prompt above, you could Ctrl-P (assuming default emacs mode) to retrieve the "ls" command and then edit it. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When send does not recognize a mime type
>I guess I kinda believe the opposite. For example send won't send a >message if it doesn't understand any of the addressees. I think that's >a good thing. The general philosophy of mh was (contrary to the UNIX >philosophy) that if anything is wrong do nothing. For various reasons >some commands (for example, sortm -- with good reason) ,violate that >rule, but at least it's a goal. Here's my problem with that ... is an "unknown" file suffix "something wrong"? Or does it really mean "send as generic binary data"? Everybody should be able to at least save application/octet-stream to their local filesystem and can then do whatever they want with it. Also, I'm wondering what other mail programs do when they're asked to send MIME content with an unrecognized file extension; it might be worthwhile to understand what the expected behavior is here. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When send does not recognize a mime type
Ken Hornstein writes: >>Could send have an option that makes an unrecognized mime type an error? > >I assume you mean an unrecognized file extension, because the MIME types >are kinda arbitrary and new ones are being added all of the time. > >Do you really want that? If a file is "unknown", the RFCs say that >the MIME type should fall back to application/octet-stream, andwe do that. >I'm on the fence about the behavior where it attempts to auto-detect text, >but I see the utility there. I'm just trying to understand why this would >be a good thing; I think send should generally try really hard to work >unless there are errors in the transport system. I guess I kinda believe the opposite. For example send won't send a message if it doesn't understand any of the addressees. I think that's a good thing. The general philosophy of mh was (contrary to the UNIX philosophy) that if anything is wrong do nothing. For various reasons some commands (for example, sortm -- with good reason) ,violate that rule, but at least it's a goal. In this instance, consider the following, not all that unlikely scenario: I intend to type cp secretName.jpg name.jpg But actually type cp secretName.jpg name.jqg Later I do ls ~/Graphs/name* to get /home/norm/Graphs/name.jqg which I pick up with my mouse to insert into the what now attach command. The file exists, so attach doesn't complain. I send the message. It is received by a Microsoft user. Neither Microsoft nor the user no what to do with the file. Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
> "rader" == rader writes: rader> "-clobber auto" please!? rader> incremented file names rader> like Firefox download does rader> "fu.gif" -> fu.gif fu(1).gif etc yeah, but can we not use ()? They really suck if you actually have to \(-type them rather than shell complete them. (And if you have fu.gif and fu(, you have to type the (...) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The attach feature
ken wrote: > >I don't remember all the places I looked and things I tried, nor do I > >remember the order in which I did them. But here are some of the things I > >tried: > > > >man attach > >man -k attach > >man whatnow (It told me the feature existed, but not much more) > >man nmh (to see if there was a relevant man page) > >man send (lots of hits for "attach" but nothing about the attach > > command) > > So I guess this is partially the fault of the way nmh works; whatnow does > some things (and implements the "attach" command) but the real mechanics > are handled by "send". Sure, once you KNOW that what attach does is add > a special header, the information in the send man page makes more sense. > > >In my humble (but correct :-) opinion there should be an attach > >man page. It would, at the very least give the basic idea, (attach > >generates certain headers which send understands), the syntax of the > >command, and pointers to other man pages. > > See, I'm not so sure about that. It's not a new command that happens > at the shell prompt; I think more information about it belongs in the > whatnow man page. I know there's a man page for "send", but that's because > it's a command. > > But I do appreciate the feedback; let me offer a counter-suggestion. How > about some expansion of the "attach" command in whatnow(1) and a pointer > to send(1), and a back-pointer in send(1) to whatnow(1). And maybe > some clarification in send(1) as well. attachments probably a mention in nmh.1 as well. there's probably also room for a paragraph, somewhere, about where and how MIME is dealt with, and where and how character sets are dealt with. either nmh.1 or mh-chart.1 could be expanded to have some notion of command topics. i just did the following quickly (based on the contents of nmh.1), and i feel like i've never used half the commands mentioned, so i'm sure it can be improved. but you get the idea -- i think something like this could replace the existing bare list in nmh.1. [btw, i just noticed that new/fnext/fprev/unseen are missing from nmh.1. nmh.1 might also make bolder reference to mh-chart.1 -- i only found mh-chart a few months ago, and now use it all the time as a quick reference.] Sending: The three principle commands for sending mail are: comp(1)- compose a message forw(1)- forward messages repl(1)- reply to a message whatnow(1) - prompting front-end for send whatnow is usually not invoked manually. it's invoked for you by one of the above commands, after you've composed a message in your editor, and before you've decided to send it. Here you can add attachments, check the recipient list, decide to quit and send it later, etc. Related utilities: ali(1) - list mail aliases anno(1)- annotate messages whom(1)- report to whom a message would go dist(1)- redistribute a message to additional addresses Advanced commands: mhbuild(1) - translate MIME composition draft send(1)- send a message sendfiles(1) - send multiple files and directories in MIME message Receiving: The primary command for receiving mail: inc(1) - incorporate new mail Related utilities: burst(1) - explode digests into messages msgchk(1) - check for messages rcvdist(1) - asynchronously redistribute new mail rcvpack(1) - append message to file rcvstore(1)- asynchronously incorporate new mail slocal(1) - asynchronously filter and deliver new mail Displaying: The primary commands for viewing mail are: next(1)- show the next message prev(1)- show the previous message show(1)- show(display) messages scan(1)- produce a one line per message scan listing Related utilities, only sometimes invoked directly: mhl(1) - produce formatted listings of nmh messages mhlist(1) - list information about content of MIME messages mhn(1) - display/list/store/cache MIME messages mhshow(1) - display MIME messages mhstore(1) - store contents of MIME messages into files Searching: Within a folder: pick(1)- select messages by content Across folders: new(1) - report on folders with new messages flist(1) - list folders with messages in given sequence(s) flists(1) - list all folders with messages in given sequence(s) folder(1) - set/list current folder/message
Re: [Nmh-workers] The attach feature
n...@dad.org writes: > I don't remember all the places I looked and things I tried, nor do I > remember the order in which I did them. But here are some o > f the things I tried: > > man whatnow (It told me the feature existed, but not much more) > > In my humble (but correct :-) opinion there should be an attach man > page. It would, at the very least give the basic idea, (attach generates > certain headers which send understands), the syntax of the command, and > pointers to other man pages. > > Sorry to be so dumb, but remember if it weren't for us dumb folks smart > people would have nothing to be superior about. > > Norman Shapiro I sort of think that "attach files add the named files to the draft as MIME attachments" Says it all. But if you don't, please feel free to add an explanatory paragraph to the page. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
-clobber [ask|auto|suffix|never|always] I do like Paul's suggestion of no/yes/other for "ask". David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
> > > "-clobber auto" please!? > > > incremented file names > > > like Firefox download does > > > "fu.gif" -> fu.gif fu(1).gif etc > > > > oh, nice. that would be much better than the wget behavior: > > fu.tar > > fu.tar.1 > > fu.tar.2 > > But can Firefox only do that because it's coming up with the `.gif' > suffix in the first place as opposed to being presented with a foo.gif > and having to recognise where it insert the increment? Not all files > have suffixes but some contain dots so it isn't just `before the final > dot'. a suffix is a suffix--at the end. a suffix in the middle--that's not a suffix, that's wrong. ? anyway, using what's after the final dot is useful for shell file name completion and applications (e.g. Firefox is confused about cert.pem.1 but not cert(1).pem.) most of time, and that's better than never useful? steve -- ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When send does not recognize a mime type
Norm wrote: > Could send have an option that makes an unrecognized mime type an error? What to do with a file without an extension (.) in its name? Or not consider that an error? How about just adding an advisory message when this happens? Or adding a whatnow command to check without sending, but I think that's more trouble than it's worth. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When send does not recognize a mime type
>Could send have an option that makes an unrecognized mime type an error? I assume you mean an unrecognized file extension, because the MIME types are kinda arbitrary and new ones are being added all of the time. Do you really want that? If a file is "unknown", the RFCs say that the MIME type should fall back to application/octet-stream, and we do that. I'm on the fence about the behavior where it attempts to auto-detect text, but I see the utility there. I'm just trying to understand why this would be a good thing; I think send should generally try really hard to work unless there are errors in the transport system. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
Hi Paul, > ra...@hep.wisc.edu wrote: > > "-clobber auto" please!? > > incremented file names > > like Firefox download does > > "fu.gif" -> fu.gif fu(1).gif etc > > oh, nice. that would be much better than the wget behavior: > fu.tar > fu.tar.1 > fu.tar.2 But can Firefox only do that because it's coming up with the `.gif' suffix in the first place as opposed to being presented with a foo.gif and having to recognise where it insert the increment? Not all files have suffixes but some contain dots so it isn't just `before the final dot'. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
> > "-clobber auto" please!? > > incremented file names > > like Firefox download does > > "fu.gif" -> fu.gif fu(1).gif etc > > oh, nice. that would be much better than the wget behavior: > fu.tar > fu.tar.1 > fu.tar.2 And... I think preserving the suffix is desireable because applications which discern file type by suffix will do the right thing. steve -- ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The attach feature
>I don't remember all the places I looked and things I tried, nor do I remember >the order in which I did them. But here are some of the things I tried: > > man attach > man -k attach > man whatnow (It told me the feature existed, but not much more) > man nmh (to see if there was a relevant man page) > man send (lots of hits for "attach" but nothing about the attach > command) So I guess this is partially the fault of the way nmh works; whatnow does some things (and implements the "attach" command) but the real mechanics are handled by "send". Sure, once you KNOW that what attach does is add a special header, the information in the send man page makes more sense. >In my humble (but correct :-) opinion there should be an attach >man page. It would, at the very least give the basic idea, (attach >generates certain headers which send understands), the syntax of the >command, and pointers to other man pages. See, I'm not so sure about that. It's not a new command that happens at the shell prompt; I think more information about it belongs in the whatnow man page. I know there's a man page for "send", but that's because it's a command. But I do appreciate the feedback; let me offer a counter-suggestion. How about some expansion of the "attach" command in whatnow(1) and a pointer to send(1), and a back-pointer in send(1) to whatnow(1). And maybe some clarification in send(1) as well. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
ra...@hep.wisc.edu wrote: > > > I looked quickly at the mhstore code last night and > > see where to insert the hook for this. That was the hard > > part. > > > > Any suggestions on adding this? > > > > -clobber [ask|suffix|never|always] > > > > "always" is the current behavior, and might be the most > > useful in scripts. But I don't think that it should remain > > the default. > > > > "never" might be a bad idea? Or the exit status could be > > a count of files that were not overwritten. > > > > I'd use "ask". > > what would "-clobber suffix" do? > (haven't been following this thread closely.) > > "-clobber auto" please!? > incremented file names > like Firefox download does > "fu.gif" -> fu.gif fu(1).gif etc oh, nice. that would be much better than the wget behavior: fu.tar fu.tar.1 fu.tar.2 the result of that behavior is that if you don't realize it happened, shell auto-completion doesn't help clue you in -- either because the filename looks complete, so you don't hit tab, or because the completion is "smart", and "knows" that tar can only deal with the first of those filenames, so it doesn't give them as choices. paul > > steve > -- > > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 51.3 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
Steve wrote: > what would "-clobber suffix" do? > (haven't been following this thread closely.) > > "-clobber auto" please!? > incremented file names > like Firefox download does > "fu.gif" -> fu.gif fu(1).gif etc "-clobber suffix" is the same as your "-clobber auto", but in the style of wget: fu.gif.1 David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
david wrote: > Norm wrote: > > > Assuming that the simpler it is the more likely it is got done > > before I die, (I was born in 1932 :-)), I vote against the suffix, > > but just not overwriting. > > It's not that much more trouble to support a suffix. > I don't have a strong feeling either way. > > > Also, I would not require surveying before writing any files. That > > is, files which would not be overwritten would be written, with a > > "continuing" error message for files which were not written. Yes, > > surveying first would be better, bet getting it done, is more > > important than perfection. > > I looked quickly at the mhstore code last night and > see where to insert the hook for this. That was the hard > part. > > Any suggestions on adding this? > > -clobber [ask|suffix|never|always] > > "always" is the current behavior, and might be the most > useful in scripts. But I don't think that it should remain > the default. > > "never" might be a bad idea? Or the exit status could be > a count of files that were not overwritten. good idea. "never" might have a place in a non-interactive usage. "ask" means "ask before overwrite", i presume, not "ask for the new name"? oh, i guess giving a new name could be one of the possible responses to "ask": overwrite file "foo.bar"? [No/yes/other] o new filename? paul > > I'd use "ask". > > David > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 50.7 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
> I looked quickly at the mhstore code last night and > see where to insert the hook for this. That was the hard > part. > > Any suggestions on adding this? > > -clobber [ask|suffix|never|always] > > "always" is the current behavior, and might be the most > useful in scripts. But I don't think that it should remain > the default. > > "never" might be a bad idea? Or the exit status could be > a count of files that were not overwritten. > > I'd use "ask". what would "-clobber suffix" do? (haven't been following this thread closely.) "-clobber auto" please!? incremented file names like Firefox download does "fu.gif" -> fu.gif fu(1).gif etc steve -- ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The attach feature
Norm wrote: > man whatnow (It told me the feature existed, but not much more) I think it's sufficient: cd directory use the directory when interpreting attachment file names pwd print the working directory for attachment files ls [ls-options] list files in the attachment working directory using the ls command attach files add the named files to the draft as MIME attachments alist [-ln] list the MIME attachments, either short, long [-l] or numbered [-n] detach [-n] files-or-numbers remove MIME attachments, either by file name or by number with -n > man nmh (to see if there was a relevant man page) > man send (lots of hits for "attach" but nothing about the attach > command) References to the description of attach in the whatnow man page should be added to those two. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
Norm wrote: > Assuming that the simpler it is the more likely it is got done > before I die, (I was born in 1932 :-)), I vote against the suffix, > but just not overwriting. It's not that much more trouble to support a suffix. I don't have a strong feeling either way. > Also, I would not require surveying before writing any files. That > is, files which would not be overwritten would be written, with a > "continuing" error message for files which were not written. Yes, > surveying first would be better, bet getting it done, is more > important than perfection. I looked quickly at the mhstore code last night and see where to insert the hook for this. That was the hard part. Any suggestions on adding this? -clobber [ask|suffix|never|always] "always" is the current behavior, and might be the most useful in scripts. But I don't think that it should remain the default. "never" might be a bad idea? Or the exit status could be a count of files that were not overwritten. I'd use "ask". David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] When send does not recognize a mime type
Could send have an option that makes an unrecognized mime type an error? Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The attach feature
Ken Hornstein writes: >If you could let us know >where you looked, we could put some pointers in the man pages. I don't remember all the places I looked and things I tried, nor do I remember the order in which I did them. But here are some of the things I tried: man attach man -k attach man whatnow (It told me the feature existed, but not much more) man nmh (to see if there was a relevant man page) man send (lots of hits for "attach" but nothing about the attach command) man post I grepped for "attach: in the /usr/local/nmh hierarchy (too many hits to be very useful. ./share/doc/nmh/README-ATTACHMENTS didn't say anything about the attach command, but it was something of a breakthrough because I finally got the hint, that somehow, somewhere, the attach command caused the stuff that man send was talking about to be generated). I sent lots of message to myself (this turned out to the most useful) In my humble (but correct :-) opinion there should be an attach man page. It would, at the very least give the basic idea, (attach generates certain headers which send understands), the syntax of the command, and pointers to other man pages. Sorry to be so dumb, but remember if it weren't for us dumb folks smart people would have nothing to be superior about. Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhstore overwriting files
David Levine writes: >Norm wrote: > >> I wonder if mhstore could have an option to not overwrite any files? >> If the option were given, then trying to do so would be an error. > >Ralph submitted a enhancement request for this almost >8 years ago: > >http://savannah.nongnu.org/bugs/?11160 > >We haven't gotten to it yet :-) > >And he suggesting adding a suffix, like wget(1), instead of >failing. wget disables that with --no-clobber. Maybe the >mhstore option should allow selection of the desired >behavior. Assuming that the simpler it is the more likely it is got done before I die, (I was born in 1932 :-)), I vote against the suffix, but just not overwriting. Also, I would not require surveying before writing any files. That is, files which would not be overwritten would be written, with a "continuing" error message for files which were not written. Yes, surveying first would be better, bet getting it done, is more important than perfection. Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
