Re: mhbuild: extraneous information in message
>> There actually aren't that many MIME types in general > >You must be new here. :-) > >https://www.iana.org/assignments/media-types/media-types.xhtml Fair enough! I guess I was thinking more along the lines of, "There really aren't that many MIME type for _email_". I'm assuming you don't get much email that includes a message/sipfrag part (although I suppose it is technically possible). --Ken
Re: mhbuild: extraneous information in message
Ralph wrote: > As an aside, in digging about freedesktop.org for answers to Michael's > remote-Chrome-opening question, I noticed an alternative to file(1) is > > $ xdg-mime query filetype canned_heat__on_the_road_again.mp3 > audio/mpeg xdg-mime delegates to the first it finds of gio info, gvfs-info, and gnomevfs-info. gio info relies on the freedesktop shared MIME info database, that's packaged in Red Hat land as shared-mime-info. It'd be easy to have m4/mimetype.m4 look for xdg-mime. I don't see a similar utility to detect encoding. David
Re: mhbuild: extraneous information in message
Hi, > I just downloaded and built the master branch, and it works correctly: > >$ /tmp/file/root/bin/file -i /tmp/session2.mp3 >/tmp/session2.mp3: audio/mpeg; charset=binary > > So that's definitely the root cause. As an aside, in digging about freedesktop.org for answers to Michael's remote-Chrome-opening question, I noticed an alternative to file(1) is $ xdg-mime query filetype canned_heat__on_the_road_again.mp3 audio/mpeg -- Cheers, Ralph.
Re: mhbuild: extraneous information in message
Hi Steffen, > For example it treats un/even reverse solidus at EOLs nice, which is > still not true as of today for shells, for example: > > #?0|kent:steffen$ echo du \ > > hey > du \\hey > #?0|kent:steffen$ dash > #kent:$ echo du \ > > das > du \das > #kent:$ I don't think the backslash at the end of the line is relevant. Trying four Bourne-alike shells, I get two outputs. A) bash$ echo foo bar foo \\bar bash$ echo foo \ > bar foo \\bar $ /bin/echo foo bar foo \\bar $ /bin/echo foo \ > bar foo \\bar B) dash$ echo foo bar foo \bar dash$ echo foo \ > bar foo \bar heirloom$ echo foo bar foo \bar heirloom$ echo foo \ > bar foo \bar Clearly, echo's argv[2] will start with two backslashes. The issue is whether echo(1) should interpret that as an escape and print out just one as seen in B. My echo(1p) here says ‘If the first operand is −n, or if any of the operands contain a character, the results are implementation-defined.’ It says that because there were two entrenched divergent implementations which couldn't be standardised, thus printf(1). -- Cheers, Ralph.
Re: mhbuild: extraneous information in message
In a message of Wed, 12 May 2021 16:29:37 -0400, Ken Hornstein writes: >>> There's no HARM in you putting entries there. But nmh doesn't read that >>> file either. >> >>Which raises the question - what is getting into the path so when Laura >>adds entries to /etc/mailcap, things start working for her? > >That's ... a good question. > >First, it's not that I don't believe Laura. But ... I have some questions >about this. Like, exactly WHAT MIME types could you not view until you >added them? Were they text types? I ask because there are simply NOT >that many text types. There actually aren't that many MIME types in >general, and I'm wondering what ones you couldn't view and how long ago >you had to add them. > >Secondly ... I knew this had come up before. Here's the earlier >message where this came up: > > https://lists.nongnu.org/archive/html/nmh-workers/2015-03/msg9.html > >The short answer is FOR DEBIAN ONLY, the distribution of nmh was at the >time configured in mhn.defaults to use a program called "run-mailcap", >and I guess that uses the mailcap file. This had a poor interaction >with some types and nmh 1.6, but Alexander Zangerl (who is the Debian >nmh maintainer) said he was going to improve that, so I don't know what >the situation is under 1.7. Ralph suggested that there weren't any >Debian-specific changes in that regard, but you'd need to look at the >mhn.defaults file on your system to see the details. > >--Ken It's very likely that when I was doing this it was nmh 1.6 that was running here. And the things I remember needing to add was a different mimetype for pgp signatures and a whole host of mimetypes for things that that supposedly generated 'internet business cards, and calendaring information', a bad idea whose time I think has come and gone. But for a while everybody seemed to be sending me one, and everybody had their own idea as to what the name of the mimetype was. Laura
Re: mhbuild: extraneous information in message
Hi Ken, > There actually aren't that many MIME types in general You must be new here. :-) https://www.iana.org/assignments/media-types/media-types.xhtml -- Cheers, Ralph.
Re: mhbuild: extraneous information in message
>‘pacman -Qi mailcap’ will query for information on that package and show >the upstream URL is https://pagure.io/mailcap. Pagure is like a >SourceForge or GitLab and that installation is Fedora's, despite the >misleading domain name: https://pagure.io/about/. Fedora took Red Hat's >source. Thanks for that! >I've access to a Manjaro system. After a ‘sudo -i pacman -Syu’ to >ensure its packages are up to date, I see > >$ pacman -Q file >file 5.40-2 >$ file -i /usr/share/mathjax2/extensions/a11y/invalid_keypress.mp3 >/usr/share/mathjax2/extensions/a11y/invalid_keypress.mp3: > audio/mpegapplication/octet-stream; charset=binary >$ b2sum -l32 /usr/share/mathjax2/extensions/a11y/invalid_keypress.mp3 >c7d7c71d /usr/share/mathjax2/extensions/a11y/invalid_keypress.mp3 Right. Last night I reported that Manjaro had version 5.38-3, but that was based on what I read at https://discover.manjaro.org/packages/file rather than what's actually on my machine. It turns out that I have the same version you do. >So the bug is there. Does it report >‘audio/mpegapplication/octet-stream’ for lots of your MP3 files? Yes. As an experiment, I ran file -i on 2243 MP3 files; two were reported as application/octet-stream, with all of the remaining 2241 reported as audio/mpegapplication/octet-stream. >On both machines, ‘pacman -Qi file’ reports that package's upstream is >https://www.darwinsys.com/file/. ...which links to https://github.com/file/file I just downloaded and built the master branch, and it works correctly: $ /tmp/file/root/bin/file -i /tmp/session2.mp3 /tmp/session2.mp3: audio/mpeg; charset=binary So that's definitely the root cause. Thanks again for all your help on this! - Steven -- ___ Steven Winikoff | Montreal, QC, Canada | "Do not meddle in the affairs of dragons, s...@smwonline.ca | for you are crunchy and good with ketchup." http://smwonline.ca |
Re: mhbuild: extraneous information in message
Ken Hornstein wrote in <20210512224215.9969ccd...@pb-smtp1.pobox.com>: |>nmh could adapt or build upon the src/mx/mailcap.c of my MUA. It |>is pretty much standing on its own feet, has matured (there were |>a few hmm nits), and offers really nice extensions like |>x-mailx-test-once, x-mailx-ignore etc. | |Thank you for that offer. And forgive me if this is a stupid question, |but ... which MUA is that? :-) Oh, no problem ;) This is a mailx clone yet called s-nail. The code in question is at [1]. If you are interested in mailcap, what really may be of interest, is reading our manual, for example at [2] (there with links), i tried to collect what could be found "all" around (the same is true for .netrc which follows in the next section). [1] https://git.sdaoden.eu/browse?p=s-nail.git;a=blob;f=src/mx/mailcap.c;hb=refs/heads/next [2] https://www.sdaoden.eu/code-nail.html#37 P.S.: the formatting of [2] is a bit unfortunate, it is plain output of groff's html driver which often places indendation of list items wrong. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: mhbuild: extraneous information in message
>nmh could adapt or build upon the src/mx/mailcap.c of my MUA. It >is pretty much standing on its own feet, has matured (there were >a few hmm nits), and offers really nice extensions like >x-mailx-test-once, x-mailx-ignore etc. Thank you for that offer. And forgive me if this is a stupid question, but ... which MUA is that? :-) --Ken
Re: mhbuild: extraneous information in message
Ralph Corderoy wrote in
<20210512202431.3d70322...@orac.inputplus.co.uk>:
|Hi Valdis,
|
|> Which raises the question - what is getting into the path so when
|> Laura adds entries to /etc/mailcap, things start working for her?
|
|Ken suggested some distros might alter nmh's release when packaging to
|use mailcap(5). Looking at
|https://sources.debian.org/patches/nmh/1.7.1-4/, which I think Laura is
|uses, nothing stands out as adding that for Debian.
nmh could adapt or build upon the src/mx/mailcap.c of my MUA. It
is pretty much standing on its own feet, has matured (there were
a few hmm nits), and offers really nice extensions like
x-mailx-test-once, x-mailx-ignore etc.
Despite its deficiencies (as stated on BOF, and that
"nametemplate" format can only be at front as in %s.pdf not
pdf.%s), it parses pretty well and complains on bugs like so, too
(in the RFC 1524 example for example which in turn comes from
decade old predecessor i have forgotten what that was all about).
Of course it sits on our (still deficient) internal infrastructure
for child processes ("test" field), temporary files, LOFI
alloca(3) replacement etc. Anyhow, if so, should be taken from
[next] branch because there were some cosmetic changes which make
it look nicer. :) You know. For example it treats un/even
reverse solidus at EOLs nice, which is still not true as of today
for shells, for example:
#?0|kent:steffen$ echo du \
> hey
du \\hey
#?0|kent:steffen$ dash
#kent:$ echo du \
> das
du \das
#kent:$
(That should maybe be reported. I think i am subscribed, will do.)
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: mhbuild: extraneous information in message
>> There's no HARM in you putting entries there. But nmh doesn't read that >> file either. > >Which raises the question - what is getting into the path so when Laura >adds entries to /etc/mailcap, things start working for her? That's ... a good question. First, it's not that I don't believe Laura. But ... I have some questions about this. Like, exactly WHAT MIME types could you not view until you added them? Were they text types? I ask because there are simply NOT that many text types. There actually aren't that many MIME types in general, and I'm wondering what ones you couldn't view and how long ago you had to add them. Secondly ... I knew this had come up before. Here's the earlier message where this came up: https://lists.nongnu.org/archive/html/nmh-workers/2015-03/msg9.html The short answer is FOR DEBIAN ONLY, the distribution of nmh was at the time configured in mhn.defaults to use a program called "run-mailcap", and I guess that uses the mailcap file. This had a poor interaction with some types and nmh 1.6, but Alexander Zangerl (who is the Debian nmh maintainer) said he was going to improve that, so I don't know what the situation is under 1.7. Ralph suggested that there weren't any Debian-specific changes in that regard, but you'd need to look at the mhn.defaults file on your system to see the details. --Ken
Re: mhbuild: extraneous information in message
Hi Valdis, > Which raises the question - what is getting into the path so when > Laura adds entries to /etc/mailcap, things start working for her? Ken suggested some distros might alter nmh's release when packaging to use mailcap(5). Looking at https://sources.debian.org/patches/nmh/1.7.1-4/, which I think Laura is uses, nothing stands out as adding that for Debian. -- Cheers, Ralph.
Re: mhbuild: extraneous information in message
Ken wrote: > Really, you want to look at mhn.defaults. That's what nmh uses, and that > has been the ONLY thing that it uses. mhshow(1) has the details. Well, that depends. If your nmh was configured with a mimetypeproc, then that will be tried first. See the paragraph containing Content-Type in the send(1) man page. My nmh build shows: $ mhparam mimetypeproc file --brief --dereference --mime-type So, it tries to use that file(1) command before falling back to mhn.defaults. Implementation details are in m4/mimetype.m4 and sbr/mime_type.[hc]. With that file command, you can add custom entries to a ~/.magic file, though I have not had to do that for a long time. David
Re: mhbuild: extraneous information in message
On Wed, 12 May 2021 12:58:23 -0400, Ken Hornstein said: > >> Oh goodness. I had no idea. And here I have been happily editing > >> /etc/mailcap > >> every time somebody sends me something I cannot read, adding a rule about > >> how to > >> read it, and smiling contentedly when nmh starts being able to read it > >> properly. > >> > >> Where should I have been adding such rules, if not there, then? > > > >$HOME/.mailcap > > There's no HARM in you putting entries there. But nmh doesn't read that > file either. Which raises the question - what is getting into the path so when Laura adds entries to /etc/mailcap, things start working for her? pgpVPNP_CepTG.pgp Description: PGP signature
Re: mhbuild: extraneous information in message
>> Oh goodness. I had no idea. And here I have been happily editing >> /etc/mailcap >> every time somebody sends me something I cannot read, adding a rule about >> how to >> read it, and smiling contentedly when nmh starts being able to read it >> properly. >> >> Where should I have been adding such rules, if not there, then? > >$HOME/.mailcap There's no HARM in you putting entries there. But nmh doesn't read that file either. Really, you want to look at mhn.defaults. That's what nmh uses, and that has been the ONLY thing that it uses. mhshow(1) has the details. --Ken
Re: mhbuild: extraneous information in message
In a message of Wed, 12 May 2021 12:25:30 -0400, "Valdis Klētnieks" writes: >On Wed, 12 May 2021 18:16:28 +0200, Laura Creighton said: > >> Oh goodness. I had no idea. And here I have been happily editing >> /etc/mailcap >> every time somebody sends me something I cannot read, adding a rule about >> how to >> read it, and smiling contentedly when nmh starts being able to read it >> properly. >> >> Where should I have been adding such rules, if not there, then? > >$HOME/.mailcap > >Among other things, that way your personal entries are safe from operating >system >upgrades. Thank you. Laura
Re: mhbuild: extraneous information in message
On Wed, 12 May 2021 18:16:28 +0200, Laura Creighton said: > Oh goodness. I had no idea. And here I have been happily editing > /etc/mailcap > every time somebody sends me something I cannot read, adding a rule about how > to > read it, and smiling contentedly when nmh starts being able to read it > properly. > > Where should I have been adding such rules, if not there, then? $HOME/.mailcap Among other things, that way your personal entries are safe from operating system upgrades. pgpG9f82fL5jJ.pgp Description: PGP signature
Re: mhbuild: extraneous information in message
In a message of Wed, 12 May 2021 07:55:56 -0400, Ken Hornstein writes: >>Manjaro is based on Arch linux, and Arch linux is based on debian. >>My debian distro looks for such things in /etc/mailcap. I'd look there first. > >Just for the record nmh (and MH before it) has never directly used >the mailcap file. Arguably, it SHOULD, but it does not (I am aware >there are some distribution bundles of nmh which are configured to call >programs which use the mailcap file to try to figure out which helper >program to use, but in my experience none of those work very well). > >--Ken Oh goodness. I had no idea. And here I have been happily editing /etc/mailcap every time somebody sends me something I cannot read, adding a rule about how to read it, and smiling contentedly when nmh starts being able to read it properly. Where should I have been adding such rules, if not there, then? Laura
Re: mhbuild: extraneous information in message
>Manjaro is based on Arch linux, and Arch linux is based on debian. >My debian distro looks for such things in /etc/mailcap. I'd look there first. Just for the record nmh (and MH before it) has never directly used the mailcap file. Arguably, it SHOULD, but it does not (I am aware there are some distribution bundles of nmh which are configured to call programs which use the mailcap file to try to figure out which helper program to use, but in my experience none of those work very well). --Ken
Re: mhbuild: extraneous information in message
Hi Steven, >$ cat /etc/mailcap >### >### Begin Red Hat Mailcap >### ... > I'm not going to speculate on why an Arch-derived distribution has an > /etc/mailcap sourced from Red Hat. :-/ Oh, that's right, Manjaro, don't know why I asked what system in the other email! ‘pacman -Qi mailcap’ will query for information on that package and show the upstream URL is https://pagure.io/mailcap. Pagure is like a SourceForge or GitLab and that installation is Fedora's, despite the misleading domain name: https://pagure.io/about/. Fedora took Red Hat's source. I've access to a Manjaro system. After a ‘sudo -i pacman -Syu’ to ensure its packages are up to date, I see $ pacman -Q file file 5.40-2 $ file -i /usr/share/mathjax2/extensions/a11y/invalid_keypress.mp3 /usr/share/mathjax2/extensions/a11y/invalid_keypress.mp3: audio/mpegapplication/octet-stream; charset=binary $ b2sum -l32 /usr/share/mathjax2/extensions/a11y/invalid_keypress.mp3 c7d7c71d /usr/share/mathjax2/extensions/a11y/invalid_keypress.mp3 So the bug is there. Does it report ‘audio/mpegapplication/octet-stream’ for lots of your MP3 files? Back home, on an out-of-date Arch Linux, after copying that MP3 file to here: $ pacman -Q file file 5.37-2 $ file -i invalid_keypress.mp3 invalid_keypress.mp3: audio/mpeg; charset=binary On both machines, ‘pacman -Qi file’ reports that package's upstream is https://www.darwinsys.com/file/. -- Cheers, Ralph.
Re: mhbuild: extraneous information in message
>Also .deb files just install on Arch, no? (been a long time since I had >one.) No, Arch uses its own package manager: https://wiki.archlinux.org/title/pacman Details for the file package in Arch are here: https://archlinux.org/packages/core/x86_64/file/ The current version is 5.40-3, and Ralph is right: the current version for the same package in Manjaro (which sources packages from Arch, but releases them from its own repositories after testing) is 5.38-3. It's 6:02 am in this timezone and I definitely need sleep, but the next thing to try is to grab the 5.40 package from Arch and see what happens. - Steven -- ___ Steven Winikoff | Montreal, QC, Canada | "If you're not part of the solution, s...@smwonline.ca | you're part of the precipitate." http://smwonline.ca | |- Steven Wright
Re: mhbuild: extraneous information in message
>I think it's a file(1) bug in the executable, probably known and fixed >upstream. That would make sense, and I'll follow it up in that direction (after getting some sleep :-/). >What system are you running, e.g. Ubuntu, and its version? Like Arch, Manjaro is a rolling release, so the number doesn't actually mean very much -- but for what it's worth, $ cat /etc/lsb-release DISTRIB_ID=ManjaroLinux DISTRIB_RELEASE=21.0.4 DISTRIB_CODENAME=Ornara DISTRIB_DESCRIPTION="Manjaro Linux" I do keep up with updates, and as I write this there are none pending. - Steven -- ___ Steven Winikoff | "The difference between the right word and Montreal, QC, Canada | the nearly right word is the difference s...@smwonline.ca | between the lightning and the lightning http://smwonline.ca | bug." | - Mark Twain
Re: mhbuild: extraneous information in message
Hi Steven,
> >- What does ‘file -i’ give on the MP3 file?
>
> ...Aha! You nailed it:
>
>$ file -i /tmp/session2.mp3
>/tmp/session2.mp3: audio/mpegapplication/octet-stream; charset=binary
>
> ...and similarly,
>
>$ file --mime-type /tmp/session2.mp3
>/tmp/session2.mp3: audio/mpegapplication/octet-stream
Yes, that look non-optimal.
> With no options, file reports
>
>$ file /tmp/session2.mp3
>/tmp/session2.mp3: Audio file with ID3 version 2.4.0, contains:MPEG ADTS,
> layer III, v1, 64 kbps, 48 kHz, Stereo
Its order of tests can give strange results. :-)
$ file $f
steelers_wheel__stuck_in_the_middle_with_you.mp3: GEM GDOS font 50304, ID
0xf3ff
$ file -i $f
steelers_wheel__stuck_in_the_middle_with_you.mp3: application/x-font-gdos;
charset=binary
> Running strace on file lists the following openat() calls:
>
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/usr/lib/libmagic.so.1", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/usr/lib/libseccomp.so.2", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/usr/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/usr/lib/liblzma.so.5", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/usr/lib/libbz2.so.1.0", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/usr/lib/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, 0x555892c2d4f0, O_RDONLY) = 3
> openat(AT_FDCWD, 0x153f7cb54848, O_RDONLY) = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, 0x7ffc2a816a10, O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, 0x7ffc2a819209, O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 3
>
> ...which includes none of the files I expected to see.
Interesting lines from ‘strace -fe %file’ here are
execve("/usr/bin/file", ["file", "-i",
"/home/music/youtube/steelers_whe"...], 0x7ffcf3fa2500 /* 70 vars */) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
...
openat(AT_FDCWD, "/usr/lib/libmagic.so.1", O_RDONLY|O_CLOEXEC) = 3
...
stat("/home/ralph/.magic.mgc", 0x7ffd781d5190) = -1 ENOENT (No such file or
directory)
stat("/home/ralph/.magic", 0x7ffd781d5190) = -1 ENOENT (No such file or
directory)
access("/usr/share/file/misc/magic.mime.mgc", R_OK) = -1 ENOENT (No such
file or directory)
openat(AT_FDCWD, "/usr/share/file/misc/magic.mgc", O_RDONLY) = 3
> so there's still something I'm obviously missing.
I think it's a file(1) bug in the executable, probably known and fixed
upstream. What system are you running, e.g. Ubuntu, and its version?
--
Cheers, Ralph.
Re: mhbuild: extraneous information in message
>My debian distro looks for such things in /etc/mailcap. I'd look there first. Thanks! ...but I suspect that may be a Clupea harengus of the crimson variety :-), partly because it was last modified more than a year ago: $ ls -l /etc/mailcap -rw-r--r-- 1 root root 272 May 5 2020 /etc/mailcap ...but mostly because it's almost empty: $ cat /etc/mailcap ### ### Begin Red Hat Mailcap ### audio/*; /usr/bin/xdg-open %s image/*; /usr/bin/xdg-open %s application/msword; /usr/bin/xdg-open %s application/pdf; /usr/bin/xdg-open %s application/postscript ; /usr/bin/xdg-open %s text/html; /usr/bin/xdg-open %s ; copiousoutput I'm not going to speculate on why an Arch-derived distribution has an /etc/mailcap sourced from Red Hat. :-/ Just for fun I tried $ /usr/bin/xdg-open /tmp/session2.mp3 I'm not sure why xdg-open decided that I want to open .mp3 files in clementine (that's a question for another time), but in fact it did so with no output other than debug messages from clementine (and why so many debug messages are emitted is also a question for another time). - Steven -- ___ Steven Winikoff | Montreal, QC, Canada | For clarity in writing, be careful about s...@smwonline.ca | word selection. For example, never http://smwonline.ca | utilize 'utilize' when you can use 'use'.
Re: mhbuild: extraneous information in message
In a message of Wed, 12 May 2021 10:12:06 +0100, Ralph Corderoy writes: >Hi Laura, > >> Manjaro is based on Arch linux, > >Yep. > >> and Arch linux is based on debian. > >No, I don't think so. I run Arch Linux here and one key reason is it >packages upstream releases directly without much tinkering or delay by >doing a ‘rolling’ release, unlike Debian which has a comprehensive set >of patches and a periodic release schedule. > >> My debian distro looks for such things in /etc/mailcap. I'd look >> there first. > >However, I have one of those, owned by the mailcap package. :-) I think I could have phrased that better. What I meant by 'based on debian' was historically, and to do with filesystem layouts and the like -- as opposed to 'based on SuSe or based on RedHat', not dependent on the technical and political machinations of the debian community. Also .deb files just install on Arch, no? (been a long time since I had one.) At any rate whenever I have the sort of problem that Steven mentioned, I just add a line to /etc/mailcap telling it how I want to process the new thing I am being sent. But other distros keep this stuff other places. Laura
Re: mhbuild: extraneous information in message
>The complaint about ‘/octet-stream’ coupled with the trailing >‘application’ after ‘audio/mpeg’ looks like two things are being >combined, e.g. ‘audio/mpeg application/octet-stream’. That makes sense. >- How do you attach the MP3 file? By typing "at /path/to/file.mp3" at the whatnow? prompt. ...and I just checked the man page for whatnow and discovered the -v option: What now? at -v /tmp/session2.mp3 Attaching /tmp/session2.mp3 as a audio/mpegapplication/octet-stream What now? s (I didn't actually send anything just now, but that's what would follow). The relevant .mh_profile entries (at least, the ones I recognize as being relevant) are: comp: -form .compform send: -msgid -messageid random -alias .aliases -port 25 mhbuild:-maxunencoded 500 >- Can we see a draft before mhbuild gets run? Sure, here's one: 8<-- cut here >8 To: s...@smwonline.ca Subject: foo Fcc: inbox From: Steven Winikoff Reply-to: Steven Winikoff Content-Type: text/plain; charset="UTF-8" Nmh-Attach: /tmp/session2.mp3 -- ___ Steven Winikoff | Montreal, QC, Canada | "The worst misunderstandings are the s...@smwonline.ca | unspoken ones." http://smwonline.ca | | - Spider Robinson 8<-- cut here ->8 But I don't think you'll need it, because... >- What does ‘file -i’ give on the MP3 file? ...Aha! You nailed it: $ file -i /tmp/session2.mp3 /tmp/session2.mp3: audio/mpegapplication/octet-stream; charset=binary ...and similarly, $ file --mime-type /tmp/session2.mp3 /tmp/session2.mp3: audio/mpegapplication/octet-stream I hadn't known about the -i option until you suggested it, and I found --mime-type just now while looking up -i. With no options, file reports $ file /tmp/session2.mp3 /tmp/session2.mp3: Audio file with ID3 version 2.4.0, contains:MPEG ADTS, layer III, v1, 64 kbps, 48 kHz, Stereo Running strace on file lists the following openat() calls: openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/libmagic.so.1", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/libseccomp.so.2", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/liblzma.so.5", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/libbz2.so.1.0", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/libz.so.1", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, 0x555892c2d4f0, O_RDONLY) = 3 openat(AT_FDCWD, 0x153f7cb54848, O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, 0x7ffc2a816a10, O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, 0x7ffc2a819209, O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 3 ...which includes none of the files I expected to see. The magic database on this system is /usr/share/file/misc/magic.mgc (the text version is supported by libmagic, but doesn't exist), and suspiciously, it was modified by a recent system upgrade: $ ls -l /usr/share/file/misc/magic.mgc -rw-r--r-- 1 root root 7012776 Apr 12 12:20 /usr/share/file/misc/magic.mgc I have a backup copy from before the upgrade: $ ls -l /path/to/backup/of/misc/magic.mgc -rw-r--r-- 6 root root 6652192 Jun 16 2020 /path/to/backup/of/magic.mgc But: $ file -i -k -m /path/to/backup/of/misc/magic.mgc /tmp/session2.mp3 /tmp/session2.mp3: audio/mpegapplication/octet-stream; charset=binary ...and the atime reported by stat(1) confirms that the backup file was accessed, so there's still something I'm obviously missing. >- What's ‘folder -version’ yield? $ folder -version folder -- nmh-1.7.1 built 2019-12-16 03:09:06 + on mort - Steven -- ___ Steven Winikoff | "The best executive is one who has sense Montreal, QC, Canada | enough to pick good people to do what he s...@smwonline.ca | wants done, and self-restraint enough to http://smwonline.ca | keep from meddling with them while they | do it." | - Theodore Roosevelt
Re: mhbuild: extraneous information in message
Hi Laura, > Manjaro is based on Arch linux, Yep. > and Arch linux is based on debian. No, I don't think so. I run Arch Linux here and one key reason is it packages upstream releases directly without much tinkering or delay by doing a ‘rolling’ release, unlike Debian which has a comprehensive set of patches and a periodic release schedule. > My debian distro looks for such things in /etc/mailcap. I'd look > there first. However, I have one of those, owned by the mailcap package. :-) -- Cheers, Ralph.
Re: mhbuild: extraneous information in message
Hi Steven, > Recently I've been seeing this message when sending email with an > attached .mp3 file: > >mhbuild: extraneous information in message /home/smw/Mail/drafts/1's > Content-Type: field > (/octet-stream) > > I've appended the Fcc copy of a typical message, in which the Content-Type: > field for the attachment is > >Content-Type: audio/mpegapplication; name="session2.mp3" The complaint about ‘/octet-stream’ coupled with the trailing ‘application’ after ‘audio/mpeg’ looks like two things are being combined, e.g. ‘audio/mpeg application/octet-stream’. - How do you attach the MP3 file? - How does mhbuild get run, in case it's important, e.g. do you type ‘mime’ at whatnow(1)? - Can we see a draft before mhbuild gets run? - What does ‘file -i’ give on the MP3 file? - What's ‘folder -version’ yield? -- Cheers, Ralph.
Re: mhbuild: extraneous information in message
In a message of Wed, 12 May 2021 04:20:24 -0400, Steven Winikoff writes: >I'm quite sure this isn't nmh's fault, but rather an error in the MIME >configuration on my Manjaro Linux machine. I'm hoping for a hint about >where to look for the config file responsible for "audio/mpegapplication;". > > Thanks, > > - Steven Manjaro is based on Arch linux, and Arch linux is based on debian. My debian distro looks for such things in /etc/mailcap. I'd look there first. Laura Creighton
