I have a problem with munpack that occurs very rarely: It loses all hint Iof the mime type when it makes up a file name. It seems like it would be fairly simple to look at /etc/mime.types and tack on an extension from there. (e.g. part2.txt, part3.csh, part4.html, part5.com).
Raul Miller wrote: Hi. Can you give a specific example of an article for which munpack does the wrong thing? Hm... if munpack actually loses information, then it would be better to fix that lossage. Richard Braakman
Richard Braakman <dark@xs4all.nl> wrote: I can tell you how to construct one: go to http://www.debian.org/, in netscape use "mail document", run munpack on the resulting email message. If you look inside the resulting file you can see it's html, but mime type information is encoded in the extension.
Raul Miller wrote: send me the mail. night:[dark]/tmp: munpack testmail Did not find anything to unpack from testmail night:[dark]/tmp: munpack -t testmail part1 (text/plain) part2 (text/html) part3 (text/html) So I assume you used the -t flag? There's a problem here: if munpack simply appends an extension, you will get these filenames: part1 part1.html part2.html This is because munpack uses numbers only to keep the filenames unique. An alternative would be: txt1 html1 html2 Note that if you simply want to know what kind of files you got, you can always do: night:[dark]/tmp: file part* part1: ASCII text part2: HTML document text part3: HTML document text In any case, if you confirm that this is the situation you're talking about, I'll send your suggestion to the upstream maintainers. But don't expect too much from that direction. I sent in a bugfix four months ago and I got no response. Richard Braakman
Richard Braakman <dark@xs4all.nl> wrote: yes I see no problem with that. Or, actually, I was expecting part1.txt part2.html part3.html No need to make it complicated. If this is undesireable for some people, don't make it default behavior. [But it needs to be in the extension, or it's not very useful] This works some of the time, but what if you get "data" forinstance. Ok, if they don't respond in say, a month, would you accept a patch from me? Thanks,
Hi. I'm sorry I took so long to get back to you. Raul Miller wrote: I'm afraid that the filenames I listed are the simple case. If you want a list like you gave, you'll have to rewrite quite a bit of it. Currently munpack does not count the parts, it just picks the first "part%d" filename that does not exist yet. That way it avoids overwriting part-files from earlier messages. True, that's an option I hadn't thought of. You can send the patch earlier than that, if you want. I can pass that upstream too. And I'll be happy to include your patch in the Debian version. Richard Braakman
Richard Braakman <dark@xs4all.nl> wrote: That's fine, then. I'll see if I can get to it.
Hi. I maintain the Debian package for mpack, currently version 1.5. This means that I compile the program with all the right options and configurations for Debian Linux, and I provide the scripts and data that interface mpack with the Debian package manager. One of our users, Raul Miller <moth@test.legislate.com>, requested a new feature for munpack. Forwarded message follows: I have a problem with munpack that occurs very rarely: It loses all hint Iof the mime type when it makes up a file name. It seems like it would be fairly simple to look at /etc/mime.types and tack on an extension from there. (e.g. part2.txt, part3.csh, part4.html, part5.com). Some discussion followed, and it became clear that he refers to mails that contain anonymous mime-parts, for which munpack uses "part%d" filenames when the -t flag is given. I'm attaching a testmail which shows this behaviour. When I munpack it, I get this output: % munpack testmail Did not find anything to unpack from testmail % munpack -t testmail part1 (text/plain) part2 (text/html) part3 (text/html) What Raul Miller is asking for is that part2 and part3 be named part2.html and part3.html, presumably so that other programs (such as lynx) know what they are dealing with and can parse it appropriately. I know that adding an extension may make it difficult to keep the part numbers the same, because of the way munpack generates a unique filename. However, for some purposes the extensions are far more important than the base names, so it would be useful to have the option to add them. Will you consider adding this behaviour as an option to munpack? Thanks, Richard Braakman P.S. Please preserve the Cc to 14788-forwarded@bugs.debian.org in any replies, so that our bug tracking system will archive the correspondence.