Re: Enabling $rfc2047_parameters by default
On Sat, Jan 08, 2022 at 02:46:48PM -0800, Kevin J. McCarthy wrote: > I'm thinking about enabling $rfc2047_parameters by default, and would like > to hear any counter-arguments against this. I believe the original argument against was that doing so violates the RFCs, and therefore potentially obscures a header that actually wanted that text to appear in the header in conformance with the spec. However--and my memory on this is as vague as ever--wasn't there an update to the RFCs that expressly allowed it in headers for which it wasn't previously allowed? One certainly might raise the question of why it was originally excluded from the spec... There was probably a reason, but I don't know it. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: [PATCH] Option to clear the screen on quit
On Mon, Nov 01, 2021 at 11:47:40AM +1100, Cameron Simpson wrote: > On 17Oct2021 15:04, Oskari Pirhonen wrote: > >#! /bin/bash > > I much prefer: > #!/bin/sh > absent some special reason. /bin/sh exists on all POSIX systems, and > bash need not (and if it does, it is not always in /bin). I agree wholeheartedly, and FWIW invoking as bash changes the behavior of scripts in subtle but possibly undesireable ways. Probably won't affect most people but if you're a "power user" and use certain features of the shell (such as for example setting ENV) it can... The only downside is these days on many systems /bin/sh is dash which annoyingly behaves differently than bash, again in mostly subtle ways, but one common one you might hit is options for the echo command. > >eval $(which mutt) "$@" && clear > > Others have wondered about the "which". I wonder about the "eval", which > is just asking for attack (or unhappy accidents). Please try not to use > it. Agree on this as well. Someone commented that which is deprecated on debian unstable--this seems like a pointless and stupid change. Every Unix system I can think of has had a which command going back maybe 40 years... deprecating it has the potential to break a lot of things for as far as I can see no practical reason whatsoever. This is not progress. On Mon, Nov 01, 2021 at 11:44:25AM +1100, Cameron Simpson wrote: > On 22Oct2021 10:30, Kevin J. McCarthy wrote: > [...] > >After 25 years of this behavior, is clearing the alternate screen > >really now a security or privacy issue; against an attacker who > >evidently has access to your terminal? Hopefully we've established that it isn't. > That said, and ignoring the alternate screen, I've noted with annoyance > that "clear" in iterm doesn't erase. I don't think that's actually true--at least it isn't for me. It absolutely does clear the terminal... But what it does not do is clear the scroll-back buffer. I would prefer it did, also. It may have a setting for that which I haven't discovered. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Mutt on ubuntu 20
I recently was given a laptop by my employer, running Ubuntu 20. I have some disincentive (which I may ignore, given sufficient reason) to run what they provide. It seems to ship with mutt-1.13.2. So, now I have TWO questions... 1. Does anyone have any idea why ubuntu is shipping such an ancient version of Mutt? ;-) 2. It appears that this version of Mutt does not properly honor color commands in headers that are continued in multiple lines. Is this a bug that was found and fixed in a future version? (I can obviously download the source and try it but that takes some time I don't really have right at the moment, so if someone knows the answer, all the better). -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: [PATCH] Option to clear the screen on quit
On Mon, Jan 10, 2022 at 06:21:58PM -0600, Derek Martin wrote: > > I much prefer: > > #!/bin/sh > > absent some special reason. /bin/sh exists on all POSIX systems, and > > bash need not (and if it does, it is not always in /bin). > > I agree wholeheartedly, and FWIW invoking as bash changes the behavior Sorry for waking up this thread, I had this message postponed from 2 months ago and meant to kill it, sent it instead. ^_^; -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Mutt on ubuntu 20
On Mon, Jan 10, 2022 at 06:27:04PM -0600, Derek Martin wrote: > 1. Does anyone have any idea why ubuntu is shipping such an ancient >version of Mutt? ;-) 1.13.2 was the most recent release of mutt at the beginning of 2020 when Ubuntu 20.04 went into testing, and the OS was released only a few months later. Once testing starts, they're not going to want to upgrade versions unless a serious problem is found. It's such an ancient version because it's such an ancient OS :-) Dan
Re: Enabling $rfc2047_parameters by default
On Mon, Jan 10, 2022 at 06:08:12PM -0600, Derek Martin wrote: On Sat, Jan 08, 2022 at 02:46:48PM -0800, Kevin J. McCarthy wrote: I'm thinking about enabling $rfc2047_parameters by default, and would like to hear any counter-arguments against this. I believe the original argument against was that doing so violates the RFCs, and therefore potentially obscures a header that actually wanted that text to appear in the header in conformance with the spec. I guess it's theoretically possible someone would want an attachment named that way, but it doesn't sound likely. :-/ However--and my memory on this is as vague as ever--wasn't there an update to the RFCs that expressly allowed it in headers for which it wasn't previously allowed? If anyone else has a pointer please let me know, but I'll try to take a look. One certainly might raise the question of why it was originally excluded from the spec... There was probably a reason, but I don't know it. I think it's because 2231 both provides encoding and allows the parameters to be split across multiple lines and reassembled. The intro to the rfc also discusses the reason language information was added. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Mutt on ubuntu 20
On Mon, Jan 10, 2022 at 06:27:04PM -0600, Derek Martin wrote: 2. It appears that this version of Mutt does not properly honor color commands in headers that are continued in multiple lines. Is this a bug that was found and fixed in a future version? (I can obviously download the source and try it but that takes some time I don't really have right at the moment, so if someone knows the answer, all the better). Derek, I can't recall a recent fix pertaining to that, but perhaps I've forgotten. Can you provide a minimal reproduce of the problem? You don't have $header_color_partial set, do you? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
