Re: What's context_foil()?
Date:Thu, 13 May 2021 19:28:49 +0100 From:Ralph Corderoy Message-ID: <20210513182849.53e5c21...@orac.inputplus.co.uk> | I take you point if what you said was true, but the ‘mypath’ variable | really does hold $HOME, Yes, I see, defpath is the Path: value (I didn't look at the change you made, but at the 1.7.1 sources). In that case, by all means, change its name. kre
Re: What's context_foil()?
Date:Thu, 13 May 2021 14:27:45 +0100 From:Ralph Corderoy Message-ID: <20210513132745.a4d7821...@orac.inputplus.co.uk> No comment on the substance, but: | BTW, ‘mypath’. It's not a path as in $PATH. It's a MH path (as in mhpath or the Path: mh_profile entry). I believe that existed before $PATH was invented (but I'm not sure about the csh equivalent). It could be said that PATH is badly named, and should be PATHS - each entry is a path (in which to search for executables). It certainly isn't what I would call homedir (aka $HOME). kre
Re: What's context_foil()?
Hi, I've just changed context_foil() as it was one of the setters of ‘mypath’. > commit d8ca46fabc26469be325b73a73dcc26e70681eb5 > Author: Ralph Corderoy > Date: Thu May 13 13:46:20 2021 +0100 > > sbr/path.c: add set_mypath() to factor out repeated code. > > set_mypath() sets the existing global ‘mypath’ which really holds > the home-directory's path. As getenv(3) and getpwuid(3)'s result > can be invalidated by further library calls, a value they return is > mh_xstrdup()'d; not all the old bits of code replaced by a call to > set_mypath() were doing this. > > Also add more explicit error messages if set_mypath() has trouble > finding the home directory's path. Not really understanding context_foil()'s purpose, I was a bit wary of changing it though I expect it's a like-for-like change and everything is okay; all 117 tests pass. >From its comment, I get the rough idea. * Foil search of users .mh_profile /* We set context to NULL to indicate that no context file * is to be read. (Using /dev/null doesn't work because we * would try to lock it, which causes timeouts with some * locking methods.) */ post(8) calls it if passed the undocumented ‘-library’. nmh_init() calls it if told not to read the context file, and post(8), slocal(1), and mh-install(1) are the ones which tell it that. Why do we want to foil the search of .mh_profile and avoid reading, and presumably mainly writing, context? And is this a good way to achieve it, or just a bit of a backdoor way which fitted given it would have been awkward to do a more large-scale change? BTW, ‘mypath’. Is ‘homedir’ a better name? It's not a path as in $PATH. -- Cheers, Ralph.
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: whats the brew nmh ownership?
Hi, I wrote: > I wonder if Fedora or Debian offer something similar. Fedora's bots listen to a RabbitMQ message bus for news of software releases from Anitya at https://release-monitoring.org. ‘Anitya is a release monitoring project. ‘Its goal is to regularly check if a project has made a new release. When Anitya discovers a new release for a project, it publishes a RabbitMQ message via fedora messaging. This makes it easy to integrate with Anitya and perform actions when a new release is created for a project. For example, the Fedora project runs a service called the-new-hotness which files a Bugzilla bug against a package when the upstream project makes a new release. ‘Anitya provides a user-friendly interface [for us plebs] to add, edit, or browse projects.’ ― https://release-monitoring.org/static/docs/index.html nmh isn't in its list, though it offers various back-ends for scraping URLs with a regexp fallback option. David obviously knows when the Fedora package needs updating, but perhaps other services listen to Anitya too. -- Cheers, Ralph.
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: whats the brew nmh ownership?
Hi Ken, > Well, "brew log nmh" would actually answer this :-) (‘log’ takes a ‘--patch’ to show the changes which I use below.) > Okay, you'd have to scroll down a bit because there are a bunch of > updates that we weren't involved with in terms of OpenSSL dependencies > and the binary builds. You'd eventually see it was me that submitted > it. Your commit added nmh to HomeBrew at 1.6. Then you updated it to 1.7, and 1.7.1. After that, FX Coudert in 3e1427a3 pegged its OpenSSL dependency to 1.1. And Nanda H Krishna in 9591758f added a ‘livecheck’ which should spot when it's out of date. livecheck do url "https://download.savannah.gnu.org/releases/nmh/; regex(/href=.*?nmh[._-]v?(\d+(?:\.\d+)+)\.t/i) end If I simulate what I expect it to do using that regexp... $ wget -qO- 'https://download.savannah.gnu.org/releases/nmh/' | > grep -Pi 'href=.*?nmh[._-]v?(\d+(?:\.\d+)+)\.t' | > grep -Po '\d+(?:\.\d+)+' | > sort -Vru | > sed q 1.7.1 $ I wonder if Fedora or Debian offer something similar. Arch Linux doesn't, AFAICS from looking at its build script: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nmh > In my limited experience unless a software package is very popular > (which, sadly, nmh is not) Six installs in the last month! https://formulae.brew.sh/formula/nmh > someone in the nmh universe has to turn the crank to get it into a > distribution. Perhaps, next time, the livecheck will flag it to the general maintainers who will crank the handle? BTW, to the list generally, HomeBrew is available for Linux and is one way to get a 1.7.1 install if that's more modern than your distribution offers. Though we'd probably prefer you try building it so we hear of portability problems. -- 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.
