>> 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
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
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
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
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
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.
>‘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.
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,
>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
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
>> 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
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/,
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
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
>> 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
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
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
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
>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
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
>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,
>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
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:
>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
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
>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.
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
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
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;".
>
>
29 matches
Mail list logo
