Re: policy around 'wontfix' bug tag

[Erik Christiansen]

On 05.02.18 10:02, Michael Stone wrote:
> IIRC it started out as a YACC function in the late 80s, and is now a Bison
> (YACC+GNU extensions) library.

In that case it has a precise grammar, expressed in BNF (Backus Naur
Form), though the lexer (I've always used lex together with
yacc/bison) could add a bit of elastic if the designer had a
free-wheeling approach. The existing flexibility then arises primarily
from explicit alternatives in grammar rules.

A BNF grammar is ideal for discussing in abstraction from the code, and
could be tweaked, both to correct erroneous results, and to add
alternative syntax which is more user-immune, if that is desired.
(But GIGO can also be cured by eliminating the GI.)

In any event, the one purportedly strange grammar example presented so
far was straightforward, both in behaviour and analysis. The one other
proposed as a challenge was nothing other than dd/mm order ambiguity.
(Purely a geographically isolated input confusion, having nothing to do
with "date".)

> There are still people who work on it--the debug option added a couple
> of years ago has made it *much* easier to understand why it does the
> things that it does. I'm not sure that if I were implementing a new
> option I'd use the bison code at all (it does probably limit the
> contributor pool).

A fork, with a new name, is on open prairie. For my money, the BNF
grammar and bison is an asset. (Even if debugging shift/reduce and
reduce/reduce conflicts can necessitate resort to old notes from previous
efforts, until one is back up to speed.)

> The bigger issues aren't the choice of implementation language,
> they're 1) getting buy-in on what the replacement should look like and
> 2) getting people to use something different. It's tough, because
> almost every linux system out there has date(1) with the existing -d
> parser, and it's easier to assume that's there than to use something
> else. (E.g., it's possible to use python or perl or other scripting
> language one-liners with any number of date libraries to add much more
> maintainable date handling to their scripts, but most people just
> stick with the date(1) they know rather than using one of the
> alternatives.)

But date(1) is fine as-is, as great now as 30 years ago - better even.
If newcomers would suggest grammar extensions (in BNF), then they could
perhaps be trialled.

Perl is the quintessential write-only language, which with a bit of luck
will die out before it catches on, and is python that monstrosity which
lacks code block delimiting, and so uses indenting in lieu?

Erik

-- 
> Am I correct that perl5-porters is the proper forum for submitting
> my ideas?
I think you didn't get a reply because you used the terms "correct" and
"proper", neither of which has much meaning in Perl culture. :-)
   -Larry Wall

Re: policy around 'wontfix' bug tag

[The Wanderer]

On 2018-02-05 at 13:47, Brian wrote:

> On Mon 05 Feb 2018 at 10:24:14 -0500, The Wanderer wrote:

>> If there's an ongoing discussion on that mailing list, and one of
>> the participants wants to draw in a third person who also
>> subscribes, it's entirely appropriate to CC a reply to that third
>> party.
> 
> Definitely (whether they are known to subscribe or not).
> 
> Which brings us back to - how does one know someone is subscribed to
> a Debian mailing list?

I still fail to see why that's something we would need to know.

Whether or not the person who posted a given message is subscribed does
not change the correct replying behavior. In both cases, unless the
poster has in some way requested otherwise, replies should go to the
mailing list.

And, as you cite, the same "whether subscribed or not" applies equally
when deciding whether to CC in a new person to an ongoing discussion.

>> However, if this were to happen with me, I would not want to
>> receive *only* the mailing-list copy. I would want to receive both:
>> the mailing-list copy to go into my local archive of the mailing
>> list (and to be present in the mailing list's folder, so that it
>> appears properly threaded with other replies), and the direct copy
>> to draw my attention to the subject. (Although I would probably
>> then seek out the mailing-list copy and reply to that. But that's a
>> personal idiosyncrasy.)
> 
> Seeking out is time-consuming. A recipe for automation is given in 
> another post. It gives you everything you want.

If I'm correct in understanding which other post you're talking about:

I'm not sure that recipe does/would do everything I want, and it seems
to be specific to a mail client which I don't use and which I'm not sure
provides all the features / behaviors I want in a mail client.

It's still interesting for reference, if nothing else, however.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Reply to sender, Reply to list (was: policy around 'wontfix' bug tag)

[Ben Finney]

Richard Hector  writes:

> On 06/02/18 02:11, Vincent Lefevre wrote:
> > On 2018-02-05 01:53:02 +1300, Richard Hector wrote:
> > You should set up a "Mail-Followup-To:" for that.

For reference, this refers to one of two proposed (but never
standardised) fields “Mail-Followup-To” and “Mail-Reply-To”
https://cr.yp.to/proto/replyto.html>.

> I could do that, I'm sure (though I'm not sure how) - but I'd rather
> that someone intending to send me a private reply didn't send it to the
> list by mistake. Having to (in my case) click 'Reply to List' helps me
> not send to the list by mistake.

That's correct. The recipient isn't in a position to guess the intention
of the person composing the message; the responsibility is on the person
composing the reply, to choose “reply to sender” or “reply to list”.

If you, when composing a reply, mean to reply to the sender, use that
command in your mail client. It will go to the “Reply-To” address, or
(if that's not present) the sender address.

If you, when composing a reply, mean to reply to the mailing list, use
that command in your mail client. It will go to the declared mailing
list address (either that, or your mail client is broken for not
recognising the mailing list address in every mailing list message).

> > This is entirely your problem.
>
> The behaviour and policy of this list, when followed, does what I
> want.

Right. In particular the current list behaviour – don't alter or set
Reply-To – and Richard's messages – absence of any custom field
“Mail-Followup-To” or “Mail-Reply-To” – leaves the default behaviour,
and the default behaviour is what Richard wants.

There is often a call for changing the mailing list program so that it
manipulates the header fields for redirecting replies to sender. This is
simply a mistake, as explained in several places, e.g.
http://marc.merlins.org/netrants/reply-to-still-harmful.html>. I
didn't see anyone so far call for that alteration, but it pops up in
these discussion too often so the above document bears repeating.

As I understand it from this thread, Richard (and I, for what it's
worth) do not want to alter the default behaviour of either “reply to
sender” nor “reply to list”. Those MUA commands, if implemented per
existing standards, will each compose a message to the correct address
for the chosen function.

So the default behaviour, of the *command chosen by the person composing
a reply*, matches the reply behaviour of Richard, and I, for each of the
reply commands. This does not need any of us making any special
alterations to any message header fields.

The person composing a reply is the only one in a position to know
whether they want the “reply to sender” or “reply to list” command. (And
if they don't have one or both of those commands available, it is only
in their power to choose a better MUA.) Don't expect the mailing list,
nor individual posters, to second guess you on that.

This has all been hashed out here in the past many times, but it is good
to refresh the references and facts again.

-- 
 \ “I thought I'd begin by reading a poem by Shakespeare, but then |
  `\ I thought ‘Why should I? He never reads any of mine.’” —Spike |
_o__) Milligan |
Ben Finney

Re: [Was: Re: policy around 'wontfix' bug tag

[Richard Hector]

On 06/02/18 15:45, Michael Stone wrote:
>> ... and how do you deal with locales that have changed definition over
>> time? What was the country code for (eg) Prussia in 1752? It just gets
>> painful ...
> 
> Yes, this is more a novelty than anything. Even apart from changing
> national borders, things were seldom as uniform within a country 200+
> years ago as a single cutover date would imply, and the very concept of
> "country" is anachronistic for the cutover dates in the 16th century.
> But at least ncal tries. :) To bring things full circle to the date(1)
> discussion, note that ncal was introduced so cal could remain
> bug-compatible.

Well, as the OP, to bring it properly full circle, I should be clear
that I'm mostly happy with the reasons for not fixing these 'bugs'. I
would just like to have seen the reason with the wontfix :-)

Richard



signature.asc
Description: OpenPGP digital signature

Re: [Was: Re: policy around 'wontfix' bug tag

[Michael Stone]

On Tue, Feb 06, 2018 at 03:36:53PM +1300, Richard Hector wrote:

On 06/02/18 15:24, Michael Stone wrote:

On Tue, Feb 06, 2018 at 12:32:06PM +1100, Erik Christiansen wrote:

And for the far past, cal is superior; compare:

$ cal -3 9 1752
   August 1752  September 1752 October 1752
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
  1 1  2 14 15 16   1  2  3  4  5  6  7
2  3  4  5  6  7  8  17 18 19 20 21 22 23   8  9 10 11 12 13 14
9 10 11 12 13 14 15  24 25 26 27 28 29 30  15 16 17 18 19 20 21
16 17 18 19 20 21 22    22 23 24 25 26 27 28
23 24 25 26 27 28 29    29 30 31
30 31


Unfortunately, as cal isn't locale-aware, it's just wrong. :)
ncal handles (some) country codes.


... and how do you deal with locales that have changed definition over
time? What was the country code for (eg) Prussia in 1752? It just gets
painful ...


Yes, this is more a novelty than anything. Even apart from changing 
national borders, things were seldom as uniform within a country 200+ 
years ago as a single cutover date would imply, and the very concept 
of "country" is anachronistic for the cutover dates in the 16th century. 
But at least ncal tries. :) To bring things full circle to the date(1) 
discussion, note that ncal was introduced so cal could remain 
bug-compatible.


Mike Stone

Re: [Was: Re: policy around 'wontfix' bug tag

[Richard Hector]

On 06/02/18 15:24, Michael Stone wrote:
> On Tue, Feb 06, 2018 at 12:32:06PM +1100, Erik Christiansen wrote:
>> And for the far past, cal is superior; compare:
>>
>> $ cal -3 9 1752
>>    August 1752  September 1752 October 1752
>> Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
>>   1 1  2 14 15 16   1  2  3  4  5  6  7
>> 2  3  4  5  6  7  8  17 18 19 20 21 22 23   8  9 10 11 12 13 14
>> 9 10 11 12 13 14 15  24 25 26 27 28 29 30  15 16 17 18 19 20 21
>> 16 17 18 19 20 21 22    22 23 24 25 26 27 28
>> 23 24 25 26 27 28 29    29 30 31
>> 30 31
> 
> Unfortunately, as cal isn't locale-aware, it's just wrong. :)
> ncal handles (some) country codes.

... and how do you deal with locales that have changed definition over
time? What was the country code for (eg) Prussia in 1752? It just gets
painful ...

Richard




signature.asc
Description: OpenPGP digital signature

Re: [Was: Re: policy around 'wontfix' bug tag

[Michael Stone]

On Mon, Feb 05, 2018 at 08:13:10PM -0600, David Wright wrote:

But how would you deal with the simplest (to express) problem of all,
that of

$ date -d 1/2/18
Tue Jan  2 00:00:00 CST 2018
$

which would mean a battery of locale-specific rules.


Yup. You'd need to accept something (probably iso8601) by default, then 
require a format specifier for anything else. "locale specific 
formatting rules" is one possible format specifier, but that should be 
explicit.


Mike Stone

Re: [Was: Re: policy around 'wontfix' bug tag

[Michael Stone]

On Tue, Feb 06, 2018 at 12:32:06PM +1100, Erik Christiansen wrote:

And for the far past, cal is superior; compare:

$ cal -3 9 1752
   August 1752  September 1752 October 1752
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
  1 1  2 14 15 16   1  2  3  4  5  6  7
2  3  4  5  6  7  8  17 18 19 20 21 22 23   8  9 10 11 12 13 14
9 10 11 12 13 14 15  24 25 26 27 28 29 30  15 16 17 18 19 20 21
16 17 18 19 20 21 2222 23 24 25 26 27 28
23 24 25 26 27 28 2929 30 31
30 31


Unfortunately, as cal isn't locale-aware, it's just wrong. :)
ncal handles (some) country codes.

Mike Stone

Re: [Was: Re: policy around 'wontfix' bug tag

[David Wright]

On Tue 06 Feb 2018 at 12:32:06 (+1100), Erik Christiansen wrote:
> On 05.02.18 09:39, Greg Wooledge wrote:
> > On Sun, Feb 04, 2018 at 04:04:34PM +0100, Nicolas George wrote:
> > > All you describe is convenience for programmatic use. As I explained,
> > > this parser is meant for interactive use.
> > 
> > What on EARTH made you think THAT?
> 
> The fuzzy grammar of the date string makes programmatic use a bit
> empirical, I must admit.
> 
> > I promise you, people ARE using date -d '...' in shell scripts.
> > LOTS of people.  Hell, I've done it.(*)
> 
> A data point: I have been using "date" for a good 30 years, on hp-ux,
> SunOS, Solaris, and now linux - pretty much _exclusively_ in scripts,
> even with -d. An example still in use even scripts the "human readable"
> input:
> 
> #!/bin/bash
> [ `date '+%H'` -lt 4 ] && day="yesterday" || day="today"
> d="`date -d $day '+%a %b %_d'`"
> ...
> echo "`date -d $day '+%a %b %_d'`" $n >> ~/fetchmail_traffic
> 
> If a new formal grammar largely consistent with the "mostly free format
> human readable date string" were defined in the manpage, then that could
> be a step forward.

But how would you deal with the simplest (to express) problem of all,
that of

$ date -d 1/2/18
Tue Jan  2 00:00:00 CST 2018
$ 

which would mean a battery of locale-specific rules.

> And for the far past, cal is superior; compare:
> 
> $ cal -3 9 1752
> August 1752  September 1752 October 1752  
> Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  
>1 1  2 14 15 16   1  2  3  4  5  6  7  
>  2  3  4  5  6  7  8  17 18 19 20 21 22 23   8  9 10 11 12 13 14  
>  9 10 11 12 13 14 15  24 25 26 27 28 29 30  15 16 17 18 19 20 21  
> 16 17 18 19 20 21 2222 23 24 25 26 27 28  
> 23 24 25 26 27 28 2929 30 31  
> 30 31

That works for the British Empire at and since that time. In the years
before that, there are at least two problems with historic dates:

some places had already moved onto the Gregorian calendar years
earlier,

for dates before Lady Day, you need to know if the recorded date
was "Old Style" or "New Style", else you'll be off by one.

Cheers,
David.

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 23:39:30 (+), Brian wrote:
> On Mon 05 Feb 2018 at 15:42:32 -0600, David Wright wrote:
> 
> > On Mon 05 Feb 2018 at 19:37:45 (+), Brian wrote:
> > > On Mon 05 Feb 2018 at 13:12:45 -0600, David Wright wrote:
> > > 
> > > > On Mon 05 Feb 2018 at 18:01:08 (+), Brian wrote:
> > > > > 
> > > > > Now you have problems (or could have). The first problem is that the
> > > > > "duplicates" are not duplicates because the headers are different. The
> > > > > second problem is - which one do you wish to keep? The third problem
> > > > > (related to the second one) is the order in which the messages arrive.
> > > > > Is it the mailing list reply first or the Cc:?
> > > > 
> > > > Granted, you lose all the information in the header about how the
> > > > reply journeyed from Fred to bendel.debian.org and on to yourself
> > > > when the list copy arrives after the direct one but, unless you're
> > > > taking a special interest in how long messages are taking, what
> > > > exactly have you lost?
> > > 
> > > The original mail has been lost. As far as I am concerned. the
> > > original which was sent to me is the only thing of importance to
> > > me. If that isn't important to you and you are satisfied with a
> > > simulacrum, that's ok by me.
> > > 
> > > (The "unless you're taking a special interest in how long messages
> > > are taking" is an indication of how important a user's mail is seen
> > > to be. If the US Postal Service processed one's mail in such a 
> > > subjective manner there might be a complaint or two).
> > 
> > Again, I'm left to think of an analogy in Real Life.
> > 
> > When some companies and institutions send an important letter, they
> > will often send one by normal post and one by Recorded Delivery.
> > The first gets delivered as normal and can be picked up on return
> > from work, whereas the other may be delayed (eg, P739 card in the UK).
> > 
> > When both eventually get delivered, they can be seen to be identical,
> > though the markings on the envelopes will differ. One is not a
> > simulacrum of the other; it's a clone, a duplicate.
> 
> To my knowledge, Royal mail do not destroy one of the mails because you
> have received one already. Some ISPs are adept at it.

You seem determined to miss the point. The sender sends two identical
copies. Royal Mail delivers both of the letters. The addressee can bin
one because the paper bears the same ink marks as the other one.

> (The information conveyed by both letters is not the same. You only have
> to look at them side-by-side to see that. They are not clones. Of course,
> if you want to thow away the envelopes . But now you do not have the
> original letters).

In my analogy, the company sent two identical copies. They are
identical by definition, printed with copies=3 (one for them to file).

Similarly, the bodies of the two emails are identical. They are cloned
when they're sent by exim. Look, here is the cloning in action
(mangled to protect the innocent):

2018-02-05 13:13:18 1eimCc-EV-Nv <= david@alum U=david P=local S=1956 
id=20180205191318.GC32350@alum
2018-02-05 13:13:21 1eimCc-EV-Nv => debian-user@lists.debian.org 
R=smarthost T=remote_smtp_smarthost H=smtp.lionunicorn.co.uk [149.255.60.164] 
X=TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128 DN="OU=Domain Control 
Validated,OU=PositiveSSL Wildcard,CN=*.unlimitedwebhosting.co.uk"
2018-02-05 13:13:21 1eimCc-EV-Nv -> foo@bar R=smarthost 
T=remote_smtp_smarthost H=smtp.lionunicorn.co.uk [149.255.60.164] 
X=TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128 DN="OU=Domain Control 
Validated,OU=PositiveSSL Wildcard,CN=*.unlimitedwebhosting.co.uk"
2018-02-05 13:13:21 1eimCc-EV-Nv Completed

Cheers,
David.

Re: policy around 'wontfix' bug tag

[Richard Hector]

On 06/02/18 02:11, Vincent Lefevre wrote:
> On 2018-02-05 01:53:02 +1300, Richard Hector wrote:
>> On 05/02/18 01:44, Nicolas George wrote:
 PS - please don't cc me; I'm on the list.
>>> Done this once, but I cannot promise I will think of it later. Document
>>> your preference in your mail mail header, the standard way, so that it
>>> is automatic and works for everybody, just like I did. Too bad the list
>>> software is not properly configured to do that automatically.
>>
>> My preference is for any personal replies addressed to me to go to me,
>> and I'd use the Reply-to header (as intended) if I needed it to go
>> somewhere else. But replies to the list should go to the list (only)
>> (unless otherwise requested), as per list policy.
> 
> You should set up a "Mail-Followup-To:" for that. This is entirely
> your problem.

I could do that, I'm sure (though I'm not sure how) - but I'd rather
that someone intending to send me a private reply didn't send it to the
list by mistake. Having to (in my case) click 'Reply to List' helps me
not send to the list by mistake.

The behaviour and policy of this list, when followed, does what I want.

Richard




signature.asc
Description: OpenPGP digital signature

[Was: Re: policy around 'wontfix' bug tag

[Erik Christiansen]

On 05.02.18 09:39, Greg Wooledge wrote:
> On Sun, Feb 04, 2018 at 04:04:34PM +0100, Nicolas George wrote:
> > All you describe is convenience for programmatic use. As I explained,
> > this parser is meant for interactive use.
> 
> What on EARTH made you think THAT?

The fuzzy grammar of the date string makes programmatic use a bit
empirical, I must admit.

> I promise you, people ARE using date -d '...' in shell scripts.
> LOTS of people.  Hell, I've done it.(*)

A data point: I have been using "date" for a good 30 years, on hp-ux,
SunOS, Solaris, and now linux - pretty much _exclusively_ in scripts,
even with -d. An example still in use even scripts the "human readable"
input:

#!/bin/bash
[ `date '+%H'` -lt 4 ] && day="yesterday" || day="today"
d="`date -d $day '+%a %b %_d'`"
...
echo "`date -d $day '+%a %b %_d'`" $n >> ~/fetchmail_traffic

If a new formal grammar largely consistent with the "mostly free format
human readable date string" were defined in the manpage, then that could
be a step forward.

> If I'm a human working in an interactive shell, and I want to see "the
> date of the Sunday that occurred in the previous week", I will simply
> run cal(1) instead.  (Or for that specific example on this specific
> day, "cal 1 2018" or even "cal 2018".)  It's a lot easier than trying
> to guess which recipe you can put into date -d to get the same result.

Yes, cal is less effort. I use date interactively only when developing a
script. For me, the "mostly free format human readable date string" is
irrelevant, as it merely serves as an undocumented grammar.

> 
> (*) One specific shell script use case was "Get the last date of a given
> month."  Now, obviously you can just set up an array of hard-coded month
> ending dates, and then write a function to determine whether the current
> year is a leap year for the February case.  But if you want to do it with
> GNU date -d, then you have to guess a magic incantation that actually
> works.  Usually by trial and error.
> 
> Anyway, here's what I came up with:
> 
> lastday() {
> date +%Y-%m-%d -d "$1 1 day ago + 1 month"
> }
...

> How does it work?  Who knows!

That's quite straightforward, I submit. Omitting the "+ 1 month", your
expression is equivalent to: (with $1 substituted for example 1)

$ date +%Y-%m-%d -d "2016-03-01 - 1 day"
2016-02-29

which simply steps backward from first of the month to last of the
previous. Then stepping forward a month merely avoids the need to input
first of next month for last of this one.

> But it seems to work.  It correctly
> handles the oddball corner cases like Feb 2100 (which is not a leap
> year), and the March-that-follows-a-leap-day as well as the
> March-that-does-not-follow-a-leap-day.  So that is where I left it.

And for the far past, cal is superior; compare:

$ cal -3 9 1752
August 1752  September 1752 October 1752  
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  
   1 1  2 14 15 16   1  2  3  4  5  6  7  
 2  3  4  5  6  7  8  17 18 19 20 21 22 23   8  9 10 11 12 13 14  
 9 10 11 12 13 14 15  24 25 26 27 28 29 30  15 16 17 18 19 20 21  
16 17 18 19 20 21 2222 23 24 25 26 27 28  
23 24 25 26 27 28 2929 30 31  
30 31

with

$ date +%Y-%m-%d -d "1752-10-01 - 1 day"
date: invalid date `1752-10-01 - 1 day'

Cal delivers the goods, but date lacks the time travelling range.

Erik

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 23:20:13 (+), Brian wrote:
> On Mon 05 Feb 2018 at 15:45:54 -0600, David Wright wrote:
> 
> > On Mon 05 Feb 2018 at 20:26:46 (+), Brian wrote:
> > > On Mon 05 Feb 2018 at 13:13:18 -0600, David Wright wrote:
> > > 
> > > > On Mon 05 Feb 2018 at 18:06:34 (+), Brian wrote:
> > > > > On Mon 05 Feb 2018 at 12:53:36 -0500, Greg Wooledge wrote:
> > > > > 
> > > > > > On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> > > > > > > AfAIK. there isn't any way to determine whether a message posted 
> > > > > > > to
> > > > > > > -user is from a non-subscriber.
> > > > > > 
> > > > > > I believe some people are using the one of the X-Spam* headers
> > > > > > and looking for the LDOSUBSCRIBER substring.  Which is extremely
> > > > > > non-obvious, and probably not a vector that ordinary users can
> > > > > > easily pursue.
> > > > > 
> > > > > The presence of LDOSUBSCRIBER indicates the post is from a subscribed
> > > > > member. It absence tells you nothing about whether the person (as
> > > > > indicted by the From: header) is subscribed or not.
> > > > 
> > > > Agreed; I've never earned the privilege of that in my header.
> > > > I've sometimes wondered whether that's the reason I occasionally
> > > > fall foul of the spam filter, and have to re-post.
> > > 
> > > I cannot account for that (and I doubt listmaster will enlighten us) but
> > > this mail of yours has
> > > 
> > > Received: from david by alum with local (Exim 4.80)   
> > >
> > > (envelope-from )  
> > >
> > > id 1eimCc-EV-Nv; Mon, 05 Feb 2018 13:13:18 -0600
> > > 
> > > Received: from localhost (localhost [127.0.0.1])  
> > >
> > > by bendel.debian.org (Postfix) with QMQP  
> > >
> > > id B714B37A; Mon,  5 Feb 2018 19:13:44 + (UTC)
> > > 
> > > Very timely.
> > 
> > Is that meant to tell me something (as you wrote "but")?
> 
> I recived B714B37A 26 seconds after you posted it. Just thought you
> would like the comfort of knowing your mail traversed the system
> just as quickly as others do.

Ah, OK, the timestamps. There's no need to worry about that. Every
email I send to my wife, sitting at the same table, crosses the
Atlantic twice, typically in under a minute, and sometimes much less.

By the way, I've never looked at those "id"s given there. Looking at
the line in exim's log, I assume it's the name of the spool files
when the email is queued between mutt and exim:

2018-02-05 13:13:18 1eimCc-EV-Nv <= david@alum U=david P=local S=1956 
id=20180205191318.GC32350@alum

The id= given on this line is, of course, the invariant Message-ID
that procmail would use using to deduplicate incoming traffic.
(Just for the record.)

Cheers,
David.

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 17:07:35 (-0500), Greg Wooledge wrote:
> > > Received: from david by alum with local (Exim 4.80)
> > > (envelope-from )
> > > id 1eimCc-EV-Nv; Mon, 05 Feb 2018 13:13:18 -0600
> 
> > Is that meant to tell me something (as you wrote "but")?
> 
> Without knowing exactly what piece Brian was focusing on, I can at
> least point out that your envelope-from is unusable.  You'll never
> be able to get a bounce message at that address.  Whether that was
> your intention, or an accident, only you can say.

Poor alum wouldn't have a clue what to do with a bounced email. Like
PCs on many home LANs, it only sends. When I'm at home, all my emails
leave this one PC as it makes filing and backing up the Sent-mail
copies easier. So what you see there is mutt on alum sending an email
to exim on alum which will rewrite the From as an address in the
UK. Again, it would be pointless to bounce mail back to the point at
which it enters the Internet, my ISP, as it would never get seen by me
(assuming they found somewhere to stick it).

Cheers,
David.

Re: policy around 'wontfix' bug tag

[Jonathan de Boyne Pollard]

Michael Stone:

Anyway, if there was a simple solution someone would have implemented 
it by now.


Indeed, that is the case; and it has been around for almost as long as 
those 20 years that you have been watching people use the GNU tool.  In 
2001, Paul Jarc invented a fairly simple notation for such things; 
providing what is effectively a mini-language, made out of chaining 
programs and using environment variables for variables, with |add|, 
|sub|, |min|, |max|, |statfile|, and |match| operators.


* http://code.dogmap.org/runwhen/example/

* http://code.dogmap.org/runwhen/stamp-fmt/

* http://code.dogmap.org/runwhen/

Xe even went through the second-system-effect process of not liking the 
first way that xe implemented it.


* http://code.dogmap.org/runwhen/caldelay/

Leаh Neukirchen took the old |caldelay| idea, and turned environment 
variables into command-line options.


* https://github.com/chneukirchen/snooze

Although |add n d1s now1s match $now1s ,H=2,M=30 wake statfile started 
add $MTAI64N d1H earliest ||max $wake $earliest wake| (which is 
effectively a prefix notation which in an infix form would be something 
like |$now1s := ||now add d1s ; $||wake := ||$now1s findnextmatching 
H=2,M=30 ; $||MTAI64N||:= timestampof started ; $||earliest :=||$MTAI64N 
add d1H ; $||wake :=||$wake max $earliest|) is more along the lines that 
you were writing about earlier.  (One can imagine a pair of date 
calculator tools akin to |dc| and |bc| that understand the prefix and 
infix forms.)

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 15:42:32 -0600, David Wright wrote:

> On Mon 05 Feb 2018 at 19:37:45 (+), Brian wrote:
> > On Mon 05 Feb 2018 at 13:12:45 -0600, David Wright wrote:
> > 
> > > On Mon 05 Feb 2018 at 18:01:08 (+), Brian wrote:
> > > > 
> > > > Now you have problems (or could have). The first problem is that the
> > > > "duplicates" are not duplicates because the headers are different. The
> > > > second problem is - which one do you wish to keep? The third problem
> > > > (related to the second one) is the order in which the messages arrive.
> > > > Is it the mailing list reply first or the Cc:?
> > > 
> > > Granted, you lose all the information in the header about how the
> > > reply journeyed from Fred to bendel.debian.org and on to yourself
> > > when the list copy arrives after the direct one but, unless you're
> > > taking a special interest in how long messages are taking, what
> > > exactly have you lost?
> > 
> > The original mail has been lost. As far as I am concerned. the
> > original which was sent to me is the only thing of importance to
> > me. If that isn't important to you and you are satisfied with a
> > simulacrum, that's ok by me.
> > 
> > (The "unless you're taking a special interest in how long messages
> > are taking" is an indication of how important a user's mail is seen
> > to be. If the US Postal Service processed one's mail in such a 
> > subjective manner there might be a complaint or two).
> 
> Again, I'm left to think of an analogy in Real Life.
> 
> When some companies and institutions send an important letter, they
> will often send one by normal post and one by Recorded Delivery.
> The first gets delivered as normal and can be picked up on return
> from work, whereas the other may be delayed (eg, P739 card in the UK).
> 
> When both eventually get delivered, they can be seen to be identical,
> though the markings on the envelopes will differ. One is not a
> simulacrum of the other; it's a clone, a duplicate.

To my knowledge, Royal mail do not destroy one of the mails because you
have received one already. Some ISPs are adept at it.

(The information conveyed by both letters is not the same. You only have
to look at them side-by-side to see that. They are not clones. Of course,
if you want to thow away the envelopes . But now you do not have the
original letters).


-- 
Brian.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 15:45:54 -0600, David Wright wrote:

> On Mon 05 Feb 2018 at 20:26:46 (+), Brian wrote:
> > On Mon 05 Feb 2018 at 13:13:18 -0600, David Wright wrote:
> > 
> > > On Mon 05 Feb 2018 at 18:06:34 (+), Brian wrote:
> > > > On Mon 05 Feb 2018 at 12:53:36 -0500, Greg Wooledge wrote:
> > > > 
> > > > > On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> > > > > > AfAIK. there isn't any way to determine whether a message posted to
> > > > > > -user is from a non-subscriber.
> > > > > 
> > > > > I believe some people are using the one of the X-Spam* headers
> > > > > and looking for the LDOSUBSCRIBER substring.  Which is extremely
> > > > > non-obvious, and probably not a vector that ordinary users can
> > > > > easily pursue.
> > > > 
> > > > The presence of LDOSUBSCRIBER indicates the post is from a subscribed
> > > > member. It absence tells you nothing about whether the person (as
> > > > indicted by the From: header) is subscribed or not.
> > > 
> > > Agreed; I've never earned the privilege of that in my header.
> > > I've sometimes wondered whether that's the reason I occasionally
> > > fall foul of the spam filter, and have to re-post.
> > 
> > I cannot account for that (and I doubt listmaster will enlighten us) but
> > this mail of yours has
> > 
> > Received: from david by alum with local (Exim 4.80) 
> >  
> > (envelope-from )
> >  
> > id 1eimCc-EV-Nv; Mon, 05 Feb 2018 13:13:18 -0600
> > 
> > Received: from localhost (localhost [127.0.0.1])
> >  
> > by bendel.debian.org (Postfix) with QMQP
> >  
> > id B714B37A; Mon,  5 Feb 2018 19:13:44 + (UTC)
> > 
> > Very timely.
> 
> Is that meant to tell me something (as you wrote "but")?

I recived B714B37A 26 seconds after you posted it. Just thought you
would like the comfort of knowing your mail traversed the system
just as quickly as others do.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[Greg Wooledge]

> > Received: from david by alum with local (Exim 4.80)
> > (envelope-from )
> > id 1eimCc-EV-Nv; Mon, 05 Feb 2018 13:13:18 -0600

> Is that meant to tell me something (as you wrote "but")?

Without knowing exactly what piece Brian was focusing on, I can at
least point out that your envelope-from is unusable.  You'll never
be able to get a bounce message at that address.  Whether that was
your intention, or an accident, only you can say.

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 20:26:46 (+), Brian wrote:
> On Mon 05 Feb 2018 at 13:13:18 -0600, David Wright wrote:
> 
> > On Mon 05 Feb 2018 at 18:06:34 (+), Brian wrote:
> > > On Mon 05 Feb 2018 at 12:53:36 -0500, Greg Wooledge wrote:
> > > 
> > > > On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> > > > > AfAIK. there isn't any way to determine whether a message posted to
> > > > > -user is from a non-subscriber.
> > > > 
> > > > I believe some people are using the one of the X-Spam* headers
> > > > and looking for the LDOSUBSCRIBER substring.  Which is extremely
> > > > non-obvious, and probably not a vector that ordinary users can
> > > > easily pursue.
> > > 
> > > The presence of LDOSUBSCRIBER indicates the post is from a subscribed
> > > member. It absence tells you nothing about whether the person (as
> > > indicted by the From: header) is subscribed or not.
> > 
> > Agreed; I've never earned the privilege of that in my header.
> > I've sometimes wondered whether that's the reason I occasionally
> > fall foul of the spam filter, and have to re-post.
> 
> I cannot account for that (and I doubt listmaster will enlighten us) but
> this mail of yours has
> 
> Received: from david by alum with local (Exim 4.80)   
>
> (envelope-from )  
>
> id 1eimCc-EV-Nv; Mon, 05 Feb 2018 13:13:18 -0600
> 
> Received: from localhost (localhost [127.0.0.1])  
>
> by bendel.debian.org (Postfix) with QMQP  
>
> id B714B37A; Mon,  5 Feb 2018 19:13:44 + (UTC)
> 
> Very timely.

Is that meant to tell me something (as you wrote "but")?

Cheers,
David.

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 19:37:45 (+), Brian wrote:
> On Mon 05 Feb 2018 at 13:12:45 -0600, David Wright wrote:
> 
> > On Mon 05 Feb 2018 at 18:01:08 (+), Brian wrote:
> > > 
> > > Now you have problems (or could have). The first problem is that the
> > > "duplicates" are not duplicates because the headers are different. The
> > > second problem is - which one do you wish to keep? The third problem
> > > (related to the second one) is the order in which the messages arrive.
> > > Is it the mailing list reply first or the Cc:?
> > 
> > Granted, you lose all the information in the header about how the
> > reply journeyed from Fred to bendel.debian.org and on to yourself
> > when the list copy arrives after the direct one but, unless you're
> > taking a special interest in how long messages are taking, what
> > exactly have you lost?
> 
> The original mail has been lost. As far as I am concerned. the
> original which was sent to me is the only thing of importance to
> me. If that isn't important to you and you are satisfied with a
> simulacrum, that's ok by me.
> 
> (The "unless you're taking a special interest in how long messages
> are taking" is an indication of how important a user's mail is seen
> to be. If the US Postal Service processed one's mail in such a 
> subjective manner there might be a complaint or two).

Again, I'm left to think of an analogy in Real Life.

When some companies and institutions send an important letter, they
will often send one by normal post and one by Recorded Delivery.
The first gets delivered as normal and can be picked up on return
from work, whereas the other may be delayed (eg, P739 card in the UK).

When both eventually get delivered, they can be seen to be identical,
though the markings on the envelopes will differ. One is not a
simulacrum of the other; it's a clone, a duplicate.

My point about transit times was only to acknowledge that there are
occasional discussions on mailing lists about the time it takes posts
to play pinball round the various bits of bendel (for this particular
list), which depend on having the list version of the header. So an
email which was Cc'd to you as well as posted on the list could lose
you the grand total of one data point. No big deal. Nothing to do with
all the rest of your email, nor with USPS/snail mail.

Cheers,
David.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 13:13:18 -0600, David Wright wrote:

> On Mon 05 Feb 2018 at 18:06:34 (+), Brian wrote:
> > On Mon 05 Feb 2018 at 12:53:36 -0500, Greg Wooledge wrote:
> > 
> > > On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> > > > AfAIK. there isn't any way to determine whether a message posted to
> > > > -user is from a non-subscriber.
> > > 
> > > I believe some people are using the one of the X-Spam* headers
> > > and looking for the LDOSUBSCRIBER substring.  Which is extremely
> > > non-obvious, and probably not a vector that ordinary users can
> > > easily pursue.
> > 
> > The presence of LDOSUBSCRIBER indicates the post is from a subscribed
> > member. It absence tells you nothing about whether the person (as
> > indicted by the From: header) is subscribed or not.
> 
> Agreed; I've never earned the privilege of that in my header.
> I've sometimes wondered whether that's the reason I occasionally
> fall foul of the spam filter, and have to re-post.

I cannot account for that (and I doubt listmaster will enlighten us) but
this mail of yours has

Received: from david by alum with local (Exim 4.80) 
 
(envelope-from )
 
id 1eimCc-EV-Nv; Mon, 05 Feb 2018 13:13:18 -0600

Received: from localhost (localhost [127.0.0.1])
 
by bendel.debian.org (Postfix) with QMQP
 
id B714B37A; Mon,  5 Feb 2018 19:13:44 + (UTC)

Very timely.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 13:18:29 -0600, David Wright wrote:

> On Mon 05 Feb 2018 at 19:00:16 (+), Brian wrote:
> > On Mon 05 Feb 2018 at 08:32:32 -0600, David Wright wrote:
> > 
> > > If it really worries you, the answer might be ~/.procmailrc and
> > > 
> > > :0 Wh: $HOME/msgid.lock
> > > | formail -D 19 $HOME/msgid.cache
> > > 
> > > I used it for years.
> > 
> > So has Microsoft in Exchange. They use it to delete a user's mails
> > silently. Emulating this on Debian is not to be recommended. It is
> > sad to see this idea advanced here.
> 
> The fact that someone abuses a method that you use yourself does not
> invalidate that method. There's nothing sad about the method when
> you've set it up ypurself.

So Microsoft is abusing the method but Debian system administrators who
use procmail to do the same thing are not?

But you have a good point. Users can do what they want with their own
mail. That includes deleting it using the brain-dead idea that the same
Messge-Id: indicates the same email.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 13:12:45 -0600, David Wright wrote:

> On Mon 05 Feb 2018 at 18:01:08 (+), Brian wrote:
> > 
> > Now you have problems (or could have). The first problem is that the
> > "duplicates" are not duplicates because the headers are different. The
> > second problem is - which one do you wish to keep? The third problem
> > (related to the second one) is the order in which the messages arrive.
> > Is it the mailing list reply first or the Cc:?
> 
> Granted, you lose all the information in the header about how the
> reply journeyed from Fred to bendel.debian.org and on to yourself
> when the list copy arrives after the direct one but, unless you're
> taking a special interest in how long messages are taking, what
> exactly have you lost?

The original mail has been lost. As far as I am concerned. the
original which was sent to me is the only thing of importance to
me. If that isn't important to you and you are satisfied with a
simulacrum, that's ok by me.

(The "unless you're taking a special interest in how long messages
are taking" is an indication of how important a user's mail is seen
to be. If the US Postal Service processed one's mail in such a 
subjective manner there might be a complaint or two).

-- 
Brian.

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 19:00:16 (+), Brian wrote:
> On Mon 05 Feb 2018 at 08:32:32 -0600, David Wright wrote:
> 
> > If it really worries you, the answer might be ~/.procmailrc and
> > 
> > :0 Wh: $HOME/msgid.lock
> > | formail -D 19 $HOME/msgid.cache
> > 
> > I used it for years.
> 
> So has Microsoft in Exchange. They use it to delete a user's mails
> silently. Emulating this on Debian is not to be recommended. It is
> sad to see this idea advanced here.

The fact that someone abuses a method that you use yourself does not
invalidate that method. There's nothing sad about the method when
you've set it up ypurself.

I open my front door with a key. If I give a copy to my neighbour
for safekeeping, I don't expect them to go and open it without
(a) first being given permission and (b) telling me about the
circumstances, should it ever happen.

Cheers,
David.

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 18:06:34 (+), Brian wrote:
> On Mon 05 Feb 2018 at 12:53:36 -0500, Greg Wooledge wrote:
> 
> > On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> > > AfAIK. there isn't any way to determine whether a message posted to
> > > -user is from a non-subscriber.
> > 
> > I believe some people are using the one of the X-Spam* headers
> > and looking for the LDOSUBSCRIBER substring.  Which is extremely
> > non-obvious, and probably not a vector that ordinary users can
> > easily pursue.
> 
> The presence of LDOSUBSCRIBER indicates the post is from a subscribed
> member. It absence tells you nothing about whether the person (as
> indicted by the From: header) is subscribed or not.

Agreed; I've never earned the privilege of that in my header.
I've sometimes wondered whether that's the reason I occasionally
fall foul of the spam filter, and have to re-post.

Cheers,
David.

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 18:01:08 (+), Brian wrote:
> On Mon 05 Feb 2018 at 16:09:11 +0100, to...@tuxteam.de wrote:
> 
> > On Mon, Feb 05, 2018 at 09:44:43AM -0500, The Wanderer wrote:
> > > On 2018-02-05 at 09:32, David Wright wrote:
> > 
> > [...]
> > 
> > > > :0 Wh: $HOME/msgid.lock
> > > > | formail -D 19 $HOME/msgid.cache
> > > > 
> > > > I used it for years.
> > > 
> > > I don't parse this well enough to understand what it would do, and I
> > > don't know where to find a procmail reference which would let me read up
> > > on it easily enough to understand quickly. Could you clarify?
> > 
> > The trick is in formail (contained in the package procmail). Formail is
> > a pretty generic mail parser which can be used to filter mails (or parts
> > of mails) according to different criteria. Option -D instructs it to set
> > up a Message-ID cache to drop duplicate mails (duplicate in the sense of
> > Message-ID, that is). The number after the -D limits the cache's length.
> > 
> > As a careful guy, I have this:
> > 
> >   :0 Whc: msgid.lock
> >   | formail -D 8192 ~/.procmail/msgid.cache
> >   
> >   :0 a:
> >   duplicates
> > 
> > The 'c' in the first recipe lets a copy "pass through". The second
> > rule triggers on successful execution of the first one (i.e. a cache
> > hit, "this was a duplicate") and drops the duplicate into the mailbox
> > duplicates, where I can check whether something went wrong. Needless
> > to say, I haven't had to check in the last ten years, but disk space
> > is cheap :)
> 
> Now you have problems (or could have). The first problem is that the
> "duplicates" are not duplicates because the headers are different. The
> second problem is - which one do you wish to keep? The third problem
> (related to the second one) is the order in which the messages arrive.
> Is it the mailing list reply first or the Cc:?

Granted, you lose all the information in the header about how the
reply journeyed from Fred to bendel.debian.org and on to yourself
when the list copy arrives after the direct one but, unless you're
taking a special interest in how long messages are taking, what
exactly have you lost?

(OK, your responder uses Bcc: to post to the list, so you don't know
whether this was *only* a private reply. Anyone here doing that?)

Cheers,
David.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 08:32:32 -0600, David Wright wrote:

> If it really worries you, the answer might be ~/.procmailrc and
> 
> :0 Wh: $HOME/msgid.lock
> | formail -D 19 $HOME/msgid.cache
> 
> I used it for years.

So has Microsoft in Exchange. They use it to delete a user's mails
silently. Emulating this on Debian is not to be recommended. It is
sad to see this idea advanced here.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 10:24:14 -0500, The Wanderer wrote:

> On 2018-02-05 at 10:09, to...@tuxteam.de wrote:
> 
> > On Mon, Feb 05, 2018 at 09:44:43AM -0500, The Wanderer wrote:
> >
> >> On 2018-02-05 at 09:32, David Wright wrote:
> > 
> > [...]
> > 
> >> > :0 Wh: $HOME/msgid.lock
> >> > | formail -D 19 $HOME/msgid.cache
> >> > 
> >> > I used it for years.
> > 
> >> I don't parse this well enough to understand what it would do, and I
> >> don't know where to find a procmail reference which would let me read up
> >> on it easily enough to understand quickly. Could you clarify?
> > 
> > The trick is in formail (contained in the package procmail). Formail is
> > a pretty generic mail parser which can be used to filter mails (or parts
> > of mails) according to different criteria. Option -D instructs it to set
> > up a Message-ID cache to drop duplicate mails (duplicate in the sense of
> > Message-ID, that is). The number after the -D limits the cache's length.
> 
> That wouldn't produce the behavior I want, though. Whether or not a
> "duplicate" private copy (or probably not actually duplicate, since
> mailing lists tend to modify other headers while leaving Message-ID
> alone) is inappropriate depends on context, and specifically, primarily
> on the sender's intent.

Intent is something difficult to work out. I suspect many just hit
mutt's equivalent of the "g" key. Getting upset about it is the road
to a flame war.

> There can be legitimate reasons to send a message both to mailing list
> and to a named recipient who is also subscribed to that list.

Indeed. 
 
> For example, consider a high-volume mailing list, where many subscribers
> read only part of the traffic.

Or, could we consider the BTS? Not Cc'ing a bug report submitter in a
reply runs a very high risk of leaving them out of the loop.

> If there's an ongoing discussion on that mailing list, and one of the
> participants wants to draw in a third person who also subscribes, it's
> entirely appropriate to CC a reply to that third party.

Definitely (whether they are known to subscribe or not).

Which brings us back to - how does one know someone is subscribed to a
Debian mailing list?
 
> However, if this were to happen with me, I would not want to receive
> *only* the mailing-list copy. I would want to receive both: the
> mailing-list copy to go into my local archive of the mailing list (and
> to be present in the mailing list's folder, so that it appears properly
> threaded with other replies), and the direct copy to draw my attention
> to the subject. (Although I would probably then seek out the
> mailing-list copy and reply to that. But that's a personal
> idiosyncrasy.)

Seeking out is time-consuming. A recipe for automation is given in
another post. It gives you everything you want.

> There are other possible complexifying scenarios, which distort the
> picture in other directions, but I don't have them ready to mind right
> now.

I've tried to point to some of them.

> What it boils down to is that dropping duplicate messages is only always
> appropriate when they are *complete* duplicates, in all headers (except
> possibly things like transmission path history). With a mailing list,
> that's rarely if ever the case.

(Transmission headers are not unimportant. You cannot have it both
ways; it's either a duplicate or it's not).

It's probably impossible. Determining a duplicate email solely on the
basis of an identical Message-Id: is a brain-dead idea.

-- 
Brian.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[rhkramer]

On Monday, February 05, 2018 10:02:50 AM Michael Stone wrote:
> On Mon, Feb 05, 2018 at 09:11:23AM -0500, rhkra...@gmail.com wrote:
> >I assume (I know) that the license for date is some free / open source
> >license that would allow you to incorporate the old code into a new
> >function (probably with appropriate citation / credit) and then add /
> >modify / delete code as desired.
> >
> >OK, I will say one thing--I suspect this is something like the (forget
> >what they called it)--the year 2000 problem--there is code that people
> >(and companies depend on) that is so old that the maintainers are long
> >gone, thus breaking that old function wouild be a very bad thing.
> 
> IIRC it started out as a YACC function in the late 80s, and is now a
> Bison (YACC+GNU extensions) library. There are still people who work on
> it--the debug option added a couple of years ago has made it *much*
> easier to understand why it does the things that it does. I'm not sure
> that if I were implementing a new option I'd use the bison code at all
> (it does probably limit the contributor pool). The bigger issues aren't
> the choice of implementation language, they're 1) getting buy-in on what
> the replacement should look like and 2) getting people to use something
> different. It's tough, because almost every linux system out there has
> date(1) with the existing -d parser, and it's easier to assume that's
> there than to use something else. (E.g., it's possible to use python or
> perl or other scripting language one-liners with any number of date
> libraries to add much more maintainable date handling to their scripts,
> but most people just stick with the date(1) they know rather than using
> one of the alternatives.)

Thanks for the (interesting, educational, and valid) response, but, for the 
record, I was trying to refer to all the scripts and such that use the date 
function rather than the coding of the date function itself.

Re: policy around 'wontfix' bug tag

[rhkramer]

Thanks

On Monday, February 05, 2018 09:46:54 AM Greg Wooledge wrote:

> No need to guess.  You can ask it.
> 
> wooledg:~$ date --version

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 12:53:36 -0500, Greg Wooledge wrote:

> On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> > AfAIK. there isn't any way to determine whether a message posted to
> > -user is from a non-subscriber.
> 
> I believe some people are using the one of the X-Spam* headers
> and looking for the LDOSUBSCRIBER substring.  Which is extremely
> non-obvious, and probably not a vector that ordinary users can
> easily pursue.

The presence of LDOSUBSCRIBER indicates the post is from a subscribed
member. It absence tells you nothing about whether the person (as
indicted by the From: header) is subscribed or not.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 16:09:11 +0100, to...@tuxteam.de wrote:

> On Mon, Feb 05, 2018 at 09:44:43AM -0500, The Wanderer wrote:
> > On 2018-02-05 at 09:32, David Wright wrote:
> 
> [...]
> 
> > > :0 Wh: $HOME/msgid.lock
> > > | formail -D 19 $HOME/msgid.cache
> > > 
> > > I used it for years.
> > 
> > I don't parse this well enough to understand what it would do, and I
> > don't know where to find a procmail reference which would let me read up
> > on it easily enough to understand quickly. Could you clarify?
> 
> The trick is in formail (contained in the package procmail). Formail is
> a pretty generic mail parser which can be used to filter mails (or parts
> of mails) according to different criteria. Option -D instructs it to set
> up a Message-ID cache to drop duplicate mails (duplicate in the sense of
> Message-ID, that is). The number after the -D limits the cache's length.
> 
> As a careful guy, I have this:
> 
>   :0 Whc: msgid.lock
>   | formail -D 8192 ~/.procmail/msgid.cache
>   
>   :0 a:
>   duplicates
> 
> The 'c' in the first recipe lets a copy "pass through". The second
> rule triggers on successful execution of the first one (i.e. a cache
> hit, "this was a duplicate") and drops the duplicate into the mailbox
> duplicates, where I can check whether something went wrong. Needless
> to say, I haven't had to check in the last ten years, but disk space
> is cheap :)

Now you have problems (or could have). The first problem is that the
"duplicates" are not duplicates because the headers are different. The
second problem is - which one do you wish to keep? The third problem
(related to the second one) is the order in which the messages arrive.
Is it the mailing list reply first or the Cc:?

Users of mutt have it easy:

send-hook . 'unmy_hdr Message-ID:'
send-hook 'debian-user@lists\.debian\.org' 'my_hdr Message-ID:<`date 
+"%Y%m%d%H%M%S"`noccsple...@example.com>'

A mail with NoCcsPlease in its In-Reply-To or References headers can
only have had the mailing list mail as its source. However, the CC will
not contain a List-ID: header. This makes it possible to distinguish
between a list mail and a CC. Procmail recipes based on these two
conditions can now file list mail with certainty and, if desired, delete
CCs.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[Greg Wooledge]

On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> AfAIK. there isn't any way to determine whether a message posted to
> -user is from a non-subscriber.

I believe some people are using the one of the X-Spam* headers
and looking for the LDOSUBSCRIBER substring.  Which is extremely
non-obvious, and probably not a vector that ordinary users can
easily pursue.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 09:41:20 -0500, The Wanderer wrote:

> On 2018-02-05 at 08:58, Vincent Lefevre wrote:
> 
> > On 2018-02-05 08:40:27 -0500, The Wanderer wrote:
> > 
> >> On 2018-02-05 at 08:11, Vincent Lefevre wrote:
> 
> >>> You should set up a "Mail-Followup-To:" for that. This is
> >>> entirely your problem.
> >> 
> >> That does seem to be the trend and position of the world,
> >> especially in recent years, but I disagree as a matter of
> >> philosophy.
> >> 
> >> A mailing list whose subscribers can post to it is a discussion
> >> forum.
> > 
> > However, for debian-user, non-subscribers can also post. So, for
> > mail without a "Mail-Followup-To:", it may be difficult to do the
> > "right" thing automatically.
> 
> Even for replies to messages posted by non-subscribers, replying back to
> the forum by default is still the right thing to do.

AfAIK. there isn't any way to determine whether a message posted to
-user is from a non-subscriber.
 
> If the poster wants to receive replies, it is the poster's
> responsibility to do something to cause that to happen. That can take
> the form of subscribing, or of setting mail headers, or of saying
> "please CC me on replies", or simply of reading the replies in an online
> archive or mirror of the mailing list. If the poster does not do such a
> thing, then it should be presumed that the poster does not care about
> receiving replies.

I have a feeling that it's not necessarily because they do not care but
because some users are unfamiliar with the idea of a mailing list and
engagement with it.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[The Wanderer]

On 2018-02-05 at 10:09, to...@tuxteam.de wrote:

> On Mon, Feb 05, 2018 at 09:44:43AM -0500, The Wanderer wrote:
>
>> On 2018-02-05 at 09:32, David Wright wrote:
> 
> [...]
> 
>> > :0 Wh: $HOME/msgid.lock
>> > | formail -D 19 $HOME/msgid.cache
>> > 
>> > I used it for years.
> 
>> I don't parse this well enough to understand what it would do, and I
>> don't know where to find a procmail reference which would let me read up
>> on it easily enough to understand quickly. Could you clarify?
> 
> The trick is in formail (contained in the package procmail). Formail is
> a pretty generic mail parser which can be used to filter mails (or parts
> of mails) according to different criteria. Option -D instructs it to set
> up a Message-ID cache to drop duplicate mails (duplicate in the sense of
> Message-ID, that is). The number after the -D limits the cache's length.

That wouldn't produce the behavior I want, though. Whether or not a
"duplicate" private copy (or probably not actually duplicate, since
mailing lists tend to modify other headers while leaving Message-ID
alone) is inappropriate depends on context, and specifically, primarily
on the sender's intent.

There can be legitimate reasons to send a message both to mailing list
and to a named recipient who is also subscribed to that list.

For example, consider a high-volume mailing list, where many subscribers
read only part of the traffic.

If there's an ongoing discussion on that mailing list, and one of the
participants wants to draw in a third person who also subscribes, it's
entirely appropriate to CC a reply to that third party.

However, if this were to happen with me, I would not want to receive
*only* the mailing-list copy. I would want to receive both: the
mailing-list copy to go into my local archive of the mailing list (and
to be present in the mailing list's folder, so that it appears properly
threaded with other replies), and the direct copy to draw my attention
to the subject. (Although I would probably then seek out the
mailing-list copy and reply to that. But that's a personal
idiosyncrasy.)

There are other possible complexifying scenarios, which distort the
picture in other directions, but I don't have them ready to mind right
now.

What it boils down to is that dropping duplicate messages is only always
appropriate when they are *complete* duplicates, in all headers (except
possibly things like transmission path history). With a mailing list,
that's rarely if ever the case.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: policy around 'wontfix' bug tag

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Feb 05, 2018 at 09:44:43AM -0500, The Wanderer wrote:
> On 2018-02-05 at 09:32, David Wright wrote:

[...]

> > :0 Wh: $HOME/msgid.lock
> > | formail -D 19 $HOME/msgid.cache
> > 
> > I used it for years.
> 
> I don't parse this well enough to understand what it would do, and I
> don't know where to find a procmail reference which would let me read up
> on it easily enough to understand quickly. Could you clarify?

The trick is in formail (contained in the package procmail). Formail is
a pretty generic mail parser which can be used to filter mails (or parts
of mails) according to different criteria. Option -D instructs it to set
up a Message-ID cache to drop duplicate mails (duplicate in the sense of
Message-ID, that is). The number after the -D limits the cache's length.

As a careful guy, I have this:

  :0 Whc: msgid.lock
  | formail -D 8192 ~/.procmail/msgid.cache
  
  :0 a:
  duplicates

The 'c' in the first recipe lets a copy "pass through". The second
rule triggers on successful execution of the first one (i.e. a cache
hit, "this was a duplicate") and drops the duplicate into the mailbox
duplicates, where I can check whether something went wrong. Needless
to say, I haven't had to check in the last ten years, but disk space
is cheap :)

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlp4c5cACgkQBcgs9XrR2ka+bgCfd/ZKJyaLEAqNNgDHtMcs+a43
jE4An1QkauXZ10+quCxvwIY1nBskMtM9
=YnjT
-END PGP SIGNATURE-

Re: policy around 'wontfix' bug tag

[Michael Stone]

On Mon, Feb 05, 2018 at 09:11:23AM -0500, rhkra...@gmail.com wrote:

I assume (I know) that the license for date is some free / open source license
that would allow you to incorporate the old code into a new function (probably
with appropriate citation / credit) and then add / modify / delete code as
desired.

OK, I will say one thing--I suspect this is something like the (forget what
they called it)--the year 2000 problem--there is code that people (and
companies depend on) that is so old that the maintainers are long gone, thus
breaking that old function wouild be a very bad thing.


IIRC it started out as a YACC function in the late 80s, and is now a 
Bison (YACC+GNU extensions) library. There are still people who work on 
it--the debug option added a couple of years ago has made it *much* 
easier to understand why it does the things that it does. I'm not sure 
that if I were implementing a new option I'd use the bison code at all 
(it does probably limit the contributor pool). The bigger issues aren't 
the choice of implementation language, they're 1) getting buy-in on what 
the replacement should look like and 2) getting people to use something 
different. It's tough, because almost every linux system out there has 
date(1) with the existing -d parser, and it's easier to assume that's 
there than to use something else. (E.g., it's possible to use python or 
perl or other scripting language one-liners with any number of date 
libraries to add much more maintainable date handling to their scripts, 
but most people just stick with the date(1) they know rather than using 
one of the alternatives.)


Mike Stone

Re: policy around 'wontfix' bug tag

[Greg Wooledge]

On Mon, Feb 05, 2018 at 09:11:23AM -0500, rhkra...@gmail.com wrote:
> I assume (I know) that the license for date is some free / open source 
> license 

No need to guess.  You can ask it.

wooledg:~$ date --version
date (GNU coreutils) 8.26
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

Re: policy around 'wontfix' bug tag

[The Wanderer]

On 2018-02-05 at 09:32, David Wright wrote:

> On Mon 05 Feb 2018 at 08:40:27 (-0500), The Wanderer wrote:
> 
>> On 2018-02-05 at 08:11, Vincent Lefevre wrote:

>>> You should set up a "Mail-Followup-To:" for that. This is
>>> entirely your problem.
>> 
>> That does seem to be the trend and position of the world,
>> especially in recent years, but I disagree as a matter of
>> philosophy.
>> 
>> A mailing list whose subscribers can post to it is a discussion
>> forum.
>> 
>> Replies to a message which was posted to a discussion forum should,
>> by default, go back to that forum. If the poster wants the replies
>> to go somewhere else, it is that poster's responsibility to
>> indicate this fact, whether by message headers, signature comments,
>> explicit statements in the body of the message, or some other
>> means.
>> 
>> This is just as true of offline fora as of online ones.
>> 
>> Usenet got this right, IMO, and so did all the mailing lists I
>> remember participating in back before Web fora became a
>> vaguely-viable thing. I consider it a sad thing that the precedent
>> established there seems to have been abandoned since that time.
> 
> If it really worries you, the answer might be ~/.procmailrc and

Unfortunately, I do not have my mail system set up such that mail passes
through a local procmail instance before it reaches me. My mail client
pulls mail directly from the remote server.

I am theoretically interested in the possibility of setting things up to
change that, but it's very much a back-burner low-priority interest,
which has never risen to the level of even figuring out how to start on
the actual project.

> :0 Wh: $HOME/msgid.lock
> | formail -D 19 $HOME/msgid.cache
> 
> I used it for years.

I don't parse this well enough to understand what it would do, and I
don't know where to find a procmail reference which would let me read up
on it easily enough to understand quickly. Could you clarify?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: policy around 'wontfix' bug tag

[The Wanderer]

On 2018-02-05 at 08:58, Vincent Lefevre wrote:

> On 2018-02-05 08:40:27 -0500, The Wanderer wrote:
> 
>> On 2018-02-05 at 08:11, Vincent Lefevre wrote:

>>> You should set up a "Mail-Followup-To:" for that. This is
>>> entirely your problem.
>> 
>> That does seem to be the trend and position of the world,
>> especially in recent years, but I disagree as a matter of
>> philosophy.
>> 
>> A mailing list whose subscribers can post to it is a discussion
>> forum.
> 
> However, for debian-user, non-subscribers can also post. So, for
> mail without a "Mail-Followup-To:", it may be difficult to do the
> "right" thing automatically.

Even for replies to messages posted by non-subscribers, replying back to
the forum by default is still the right thing to do.

If the poster wants to receive replies, it is the poster's
responsibility to do something to cause that to happen. That can take
the form of subscribing, or of setting mail headers, or of saying
"please CC me on replies", or simply of reading the replies in an online
archive or mirror of the mailing list. If the poster does not do such a
thing, then it should be presumed that the poster does not care about
receiving replies.

>> Replies to a message which was posted to a discussion forum should,
>> by default, go back to that forum. If the poster wants the replies
>> to go somewhere else, it is that poster's responsibility to
>> indicate this fact, whether by message headers, signature comments,
>> explicit statements in the body of the message, or some other
>> means.
> 
> I would say that to avoid ambiguities, in any case, the poster
> should use a "Mail-Followup-To:" to indicate what he wants (unless he
> doesn't care).

A: I do not see any way to achieve what I want via this mechanism.
(Especially given the variety of mailing lists to which I subscribe, and
the lack of ability to specify automatic headers dynamically that way in
any mail client with which I'm familiar.)

B: That would not bear on the question of the default. The default is
what happens when no special action is taken. If I have to take action
(in the form of ensuring that that header is set) to cause the desired
behavior to occur, then the desired behavior is not the default.

> Just like for "date -d", ambiguities should always be avoided.

It is part of my philosophy that unintentional ambiguity is anathema,
but I don't see the ambiguity here. This is just a case of disagreement
about what the default should be; each possible default is perfectly
self-consistent and produces unambiguous results as far as I can tell,
it's just that they aren't compatible with one another.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: policy around 'wontfix' bug tag

[Greg Wooledge]

On Sun, Feb 04, 2018 at 04:04:34PM +0100, Nicolas George wrote:
> All you describe is convenience for programmatic use. As I explained,
> this parser is meant for interactive use.

What on EARTH made you think THAT?

I promise you, people ARE using date -d '...' in shell scripts.
LOTS of people.  Hell, I've done it.(*)

If I'm a human working in an interactive shell, and I want to see "the
date of the Sunday that occurred in the previous week", I will simply
run cal(1) instead.  (Or for that specific example on this specific
day, "cal 1 2018" or even "cal 2018".)  It's a lot easier than trying
to guess which recipe you can put into date -d to get the same result.


(*) One specific shell script use case was "Get the last date of a given
month."  Now, obviously you can just set up an array of hard-coded month
ending dates, and then write a function to determine whether the current
year is a leap year for the February case.  But if you want to do it with
GNU date -d, then you have to guess a magic incantation that actually
works.  Usually by trial and error.

Anyway, here's what I came up with:

lastday() {
date +%Y-%m-%d -d "$1 1 day ago + 1 month"
}

Testing:

wooledg:~$ lastday 2016-03-01
2016-03-31
wooledg:~$ lastday 2016-02-01
2016-02-29
wooledg:~$ lastday 2016-01-01
2016-01-31
wooledg:~$ lastday 2000-02-01
2000-02-29
wooledg:~$ lastday 2001-02-01
2001-02-28
wooledg:~$ lastday 2100-02-01
2100-02-28
wooledg:~$ lastday 2100-03-01
2100-03-31

How does it work?  Who knows!  But it seems to work.  It correctly
handles the oddball corner cases like Feb 2100 (which is not a leap
year), and the March-that-follows-a-leap-day as well as the
March-that-does-not-follow-a-leap-day.  So that is where I left it.

That was written a long time ago.  In newer projects, I have generally
gone with the hard-coded array + is_leap_year function (but not in
bash).

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 08:40:27 (-0500), The Wanderer wrote:
> On 2018-02-05 at 08:11, Vincent Lefevre wrote:
> 
> > On 2018-02-05 01:53:02 +1300, Richard Hector wrote:
> > 
> >> On 05/02/18 01:44, Nicolas George wrote:
> 
> >>> Done this once, but I cannot promise I will think of it later.
> >>> Document your preference in your mail mail header, the standard
> >>> way, so that it is automatic and works for everybody, just like I
> >>> did. Too bad the list software is not properly configured to do
> >>> that automatically.
> >> 
> >> My preference is for any personal replies addressed to me to go to
> >> me, and I'd use the Reply-to header (as intended) if I needed it to
> >> go somewhere else. But replies to the list should go to the list
> >> (only) (unless otherwise requested), as per list policy.
> > 
> > You should set up a "Mail-Followup-To:" for that. This is entirely
> > your problem.
> 
> That does seem to be the trend and position of the world, especially in
> recent years, but I disagree as a matter of philosophy.
> 
> A mailing list whose subscribers can post to it is a discussion forum.
> 
> Replies to a message which was posted to a discussion forum should, by
> default, go back to that forum. If the poster wants the replies to go
> somewhere else, it is that poster's responsibility to indicate this
> fact, whether by message headers, signature comments, explicit
> statements in the body of the message, or some other means.
> 
> This is just as true of offline fora as of online ones.
> 
> Usenet got this right, IMO, and so did all the mailing lists I remember
> participating in back before Web fora became a vaguely-viable thing. I
> consider it a sad thing that the precedent established there seems to
> have been abandoned since that time.

If it really worries you, the answer might be ~/.procmailrc and

:0 Wh: $HOME/msgid.lock
| formail -D 19 $HOME/msgid.cache

I used it for years.

Cheers,
David.

Re: policy around 'wontfix' bug tag

[rhkramer]

On Monday, February 05, 2018 08:07:47 AM Vincent Lefevre wrote:
> On 2018-02-04 08:22:23 -0500, Michael Stone wrote:
> > On Mon, Feb 05, 2018 at 12:48:45AM +1300, Richard Hector wrote:
> > > In which case, it should refuse to accept '4/2/2018' at all, right?
> > 
> > It can't, that would break working scripts. This is the heart of the
> > problem: we know the parser is horrible, confusing, and irregular, but
> > any attempt to change it will break lots of stuff that depends on the
> > current brokenness.
> 
> It is not rare that the behavior of utilities change and break
> scripts. So, why not here, in particular for a good reason?

I'm not really going to answer the question, I think MIke Stone has answered 
it for you.  The way forward would seem (to me) to be to create a new date 
function (ndate?) (or a new option to date) that provides the desired better 
functionality.

I assume (I know) that the license for date is some free / open source license 
that would allow you to incorporate the old code into a new function (probably 
with appropriate citation / credit) and then add / modify / delete code as 
desired.

OK, I will say one thing--I suspect this is something like the (forget what 
they called it)--the year 2000 problem--there is code that people (and 
companies depend on) that is so old that the maintainers are long gone, thus 
breaking that old function wouild be a very bad thing.

Re: policy around 'wontfix' bug tag

[Vincent Lefevre]

On 2018-02-05 08:40:27 -0500, The Wanderer wrote:
> On 2018-02-05 at 08:11, Vincent Lefevre wrote:
> > On 2018-02-05 01:53:02 +1300, Richard Hector wrote:
> >> My preference is for any personal replies addressed to me to go to
> >> me, and I'd use the Reply-to header (as intended) if I needed it to
> >> go somewhere else. But replies to the list should go to the list
> >> (only) (unless otherwise requested), as per list policy.
> > 
> > You should set up a "Mail-Followup-To:" for that. This is entirely
> > your problem.
> 
> That does seem to be the trend and position of the world, especially in
> recent years, but I disagree as a matter of philosophy.
> 
> A mailing list whose subscribers can post to it is a discussion forum.

However, for debian-user, non-subscribers can also post. So, for mail
without a "Mail-Followup-To:", it may be difficult to do the "right"
thing automatically.

> Replies to a message which was posted to a discussion forum should, by
> default, go back to that forum. If the poster wants the replies to go
> somewhere else, it is that poster's responsibility to indicate this
> fact, whether by message headers, signature comments, explicit
> statements in the body of the message, or some other means.

I would say that to avoid ambiguities, in any case, the poster should
use a "Mail-Followup-To:" to indicate what he wants (unless he doesn't
care).

Just like for "date -d", ambiguities should always be avoided.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: policy around 'wontfix' bug tag

[Curt]

On 2018-02-05, Roberto C  Sánchez  wrote:
>> 
>> It is not rare that the behavior of utilities change and break
>> scripts. So, why not here, in particular for a good reason?
>> 
> It is equally common, perhaps even more so, that buggy behavior is
> retained (especially if it is not harmful) and that "correct" behavior
> require a switch or setting.  I am not personally affected by this, as
> far as I know, but as a software developer I can certainly understand
> wanting to retain backward compatibility, even when it is buggy.

That's certainly why all bona fide linux hackers in the know commiserate
so readily with Windows' bug compatibility "features".

;-)

Or maybe I should have said, *afin de mettre tout le monde d'accord*,
that the principle of bug compatibility taken to facetious extremes gets
you the entomological leviathan that is Windows.

> Regards,
>
> -Roberto
>


-- 
“True terror is to wake up one morning and discover that your high school class
is running the country.” – Kurt Vonnegut

Re: policy around 'wontfix' bug tag

[The Wanderer]

On 2018-02-05 at 08:11, Vincent Lefevre wrote:

> On 2018-02-05 01:53:02 +1300, Richard Hector wrote:
> 
>> On 05/02/18 01:44, Nicolas George wrote:

>>> Done this once, but I cannot promise I will think of it later.
>>> Document your preference in your mail mail header, the standard
>>> way, so that it is automatic and works for everybody, just like I
>>> did. Too bad the list software is not properly configured to do
>>> that automatically.
>> 
>> My preference is for any personal replies addressed to me to go to
>> me, and I'd use the Reply-to header (as intended) if I needed it to
>> go somewhere else. But replies to the list should go to the list
>> (only) (unless otherwise requested), as per list policy.
> 
> You should set up a "Mail-Followup-To:" for that. This is entirely
> your problem.

That does seem to be the trend and position of the world, especially in
recent years, but I disagree as a matter of philosophy.

A mailing list whose subscribers can post to it is a discussion forum.

Replies to a message which was posted to a discussion forum should, by
default, go back to that forum. If the poster wants the replies to go
somewhere else, it is that poster's responsibility to indicate this
fact, whether by message headers, signature comments, explicit
statements in the body of the message, or some other means.

This is just as true of offline fora as of online ones.

Usenet got this right, IMO, and so did all the mailing lists I remember
participating in back before Web fora became a vaguely-viable thing. I
consider it a sad thing that the precedent established there seems to
have been abandoned since that time.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: policy around 'wontfix' bug tag

[Vincent Lefevre]

On 2018-02-05 08:12:21 -0500, Roberto C. Sánchez wrote:
> On Mon, Feb 05, 2018 at 02:07:47PM +0100, Vincent Lefevre wrote:
> > On 2018-02-04 08:22:23 -0500, Michael Stone wrote:
> > > On Mon, Feb 05, 2018 at 12:48:45AM +1300, Richard Hector wrote:
> > > > In which case, it should refuse to accept '4/2/2018' at all, right?
> > > 
> > > It can't, that would break working scripts. This is the heart of the
> > > problem: we know the parser is horrible, confusing, and irregular, but any
> > > attempt to change it will break lots of stuff that depends on the current
> > > brokenness.
> > 
> > It is not rare that the behavior of utilities change and break
> > scripts. So, why not here, in particular for a good reason?
> > 
> It is equally common, perhaps even more so, that buggy behavior is
> retained (especially if it is not harmful) and that "correct" behavior
> require a switch or setting.  I am not personally affected by this, as
> far as I know, but as a software developer I can certainly understand
> wanting to retain backward compatibility, even when it is buggy.

It might be harmful because one silently gets a wrong date.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: policy around 'wontfix' bug tag

[Roberto C . Sánchez]

On Mon, Feb 05, 2018 at 02:07:47PM +0100, Vincent Lefevre wrote:
> On 2018-02-04 08:22:23 -0500, Michael Stone wrote:
> > On Mon, Feb 05, 2018 at 12:48:45AM +1300, Richard Hector wrote:
> > > In which case, it should refuse to accept '4/2/2018' at all, right?
> > 
> > It can't, that would break working scripts. This is the heart of the
> > problem: we know the parser is horrible, confusing, and irregular, but any
> > attempt to change it will break lots of stuff that depends on the current
> > brokenness.
> 
> It is not rare that the behavior of utilities change and break
> scripts. So, why not here, in particular for a good reason?
> 
It is equally common, perhaps even more so, that buggy behavior is
retained (especially if it is not harmful) and that "correct" behavior
require a switch or setting.  I am not personally affected by this, as
far as I know, but as a software developer I can certainly understand
wanting to retain backward compatibility, even when it is buggy.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: policy around 'wontfix' bug tag

[Vincent Lefevre]

On 2018-02-05 01:53:02 +1300, Richard Hector wrote:
> On 05/02/18 01:44, Nicolas George wrote:
> >> PS - please don't cc me; I'm on the list.
> > Done this once, but I cannot promise I will think of it later. Document
> > your preference in your mail mail header, the standard way, so that it
> > is automatic and works for everybody, just like I did. Too bad the list
> > software is not properly configured to do that automatically.
> 
> My preference is for any personal replies addressed to me to go to me,
> and I'd use the Reply-to header (as intended) if I needed it to go
> somewhere else. But replies to the list should go to the list (only)
> (unless otherwise requested), as per list policy.

You should set up a "Mail-Followup-To:" for that. This is entirely
your problem.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: policy around 'wontfix' bug tag

[Vincent Lefevre]

On 2018-02-04 08:22:23 -0500, Michael Stone wrote:
> On Mon, Feb 05, 2018 at 12:48:45AM +1300, Richard Hector wrote:
> > In which case, it should refuse to accept '4/2/2018' at all, right?
> 
> It can't, that would break working scripts. This is the heart of the
> problem: we know the parser is horrible, confusing, and irregular, but any
> attempt to change it will break lots of stuff that depends on the current
> brokenness.

It is not rare that the behavior of utilities change and break
scripts. So, why not here, in particular for a good reason?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: policy around 'wontfix' bug tag

[Michael Stone]

On Sun, Feb 04, 2018 at 06:45:16PM +0100, Nicolas George wrote:

David Wright (2018-02-04):

$ TZ=London date
Sun Feb  4 17:17:56 London 2018


$ TZ=UtterNonsense date
Sun Feb  4 17:44:00 UtterNonsense 2018

The fact that it printed the name you put and not the official name of
the time zone shows that the value is invalid. The correct value would
have been:

$ TZ=Europe/London date
Sun Feb  4 17:44:49 GMT 2018


Yup. This is worse when london is on DST:


env TZ=London date --iso=seconds -d '2018-06-04T19:15+'

2018-06-04T19:15:00+00:00

env TZ=Europe/London date --iso=seconds -d '2018-06-04T19:15+'

2018-06-04T20:15:00+01:00

I would love if that were fixable, but it's actually required by POSIX. 
(Any arbitrary string can be a timezone name, with a bunch of parameters 
specifying the offset from UTC, DST rules, etc. In the absence of 
other parameters it's a synonym for UTC.) That's a glibc thing, not a 
date(1) thing.


Mike Stone

Re: policy around 'wontfix' bug tag

[David Wright]

On Sun 04 Feb 2018 at 18:45:16 (+0100), Nicolas George wrote:
> David Wright (2018-02-04):
> > $ TZ=London date
> > Sun Feb  4 17:17:56 London 2018
> 
> $ TZ=UtterNonsense date
> Sun Feb  4 17:44:00 UtterNonsense 2018
> 
> The fact that it printed the name you put and not the official name of
> the time zone shows that the value is invalid. The correct value would
> have been:
> 
> $ TZ=Europe/London date 
> Sun Feb  4 17:44:49 GMT 2018

Which goes to show how fragile relying on a TZ that doesn't originate
from a legitimate source, of course. Which is why I have

$ ls -l .timezone
lrwxrwxrwx 1 david david 13 Jan 22 20:44 .timezone -> /etc/timezone
$ 

and

export TZ=$(cat $HOME/.timezone)

in my startup files. Oh, and also a whattime function which is a
little more careful:

$ whattime london
Europe/London 2018-02-04 18:32:45 + Sunday
$ whattime auckland
Pacific/Auckland 2018-02-05 07:33:04 +1300 Monday
$ 

Cheers,
David.

Re: policy around 'wontfix' bug tag

[Nicolas George]

David Wright (2018-02-04):
> $ TZ=London date
> Sun Feb  4 17:17:56 London 2018

$ TZ=UtterNonsense date
Sun Feb  4 17:44:00 UtterNonsense 2018

The fact that it printed the name you put and not the official name of
the time zone shows that the value is invalid. The correct value would
have been:

$ TZ=Europe/London date 
Sun Feb  4 17:44:49 GMT 2018

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: policy around 'wontfix' bug tag

[David Wright]

On Sun 04 Feb 2018 at 17:44:54 (+0100), Thomas Schmitt wrote:
> Hi,
> 
> Mike Stone wrote:
> > So it must be that "first tuesday" means
> > the first tuesday in the month, but "second tuesday" sadly means the first
> > tuesday plus one second because "second" has more than one meaning and I
> > wanted the other one.
> 
> This illustrates the fundamental problem with natural english language,
> in one miniature picture.

And another:

$ date -d 'this monday'
Mon Feb  5 00:00:00 CST 2018
$ date -d 'next monday'
Mon Feb  5 00:00:00 CST 2018
$ 

Let's face it, the C locale is just American: they got there first.
Dealing with American dates/"freeway" exits and 101 other things is
just as tricky in Real Life.

[I haven't yet seen Mike's posting quoted above.]

Cheers,
David.

Re: policy around 'wontfix' bug tag

[David Wright]

On Sun 04 Feb 2018 at 14:39:44 (+0100), Thomas Schmitt wrote:
> Hi,
> 
> Richard Hector wrote:
> > Incidentally, the gnu 'Date input formats' link above does talk about
> > only accepting English names for days and months, but doesn't say
> > anything about the ordering of day and month (except, under 'General
> > date syntax', saying that 'Order of the items is immaterial' ...)
> 
> The preamble quote tells a lot about the disillusion of the writer
> of "Date input formats".
> 
> The disease is much less obvious in german language, though. There you
> need to go down to quarter hours and regional habits to get truely ambigous.
> In english i sometimes have to riddle whether a date is Day/Month/Year or
> Month/Day/Year. Whatever the rules are, writers seem confused about them.
> Possibly because so many of us aliens are around.
> 
> And what should human or machine think of my mail client's idea about
> when you sent your mail ?
> 
>Tomorrow   Richard Hector  Re: policy around 'wontfix' bug tag 

I don't know how you did that, but here:

$ date --debug -d "Mon, 5 Feb 2018 01:25:36 +1300"
date: parsed day part: Mon (day ordinal=0 number=1)
date: parsed date part: (Y-M-D) 2018-02-05
date: parsed time part: 01:25:36 TZ=+13:00
date: input timezone: +13:00 (set from parsed date/time string)
date: using specified time as starting value: '01:25:36'
date: warning: day (Mon) ignored when explicit dates are given
date: starting date/time: '(Y-M-D) 2018-02-05 01:25:36 TZ=+13:00'
date: '(Y-M-D) 2018-02-05 01:25:36 TZ=+13:00' = 1517747136 epoch-seconds
date: output timezone: -06:00 (set from TZ="US/Central" environment value)
date: final: 1517747136.0 (epoch-seconds)
date: final: (Y-M-D) 2018-02-04 12:25:36 (UTC0)
date: final: (Y-M-D) 2018-02-04 06:25:36 (output timezone TZ=-06:00)
Sun Feb  4 06:25:36 CST 2018
$ 

and

$ TZ=London date
Sun Feb  4 17:17:56 London 2018
$ TZ=NZ date
Mon Feb  5 06:17:58 NZDT 2018
$ date
Sun Feb  4 11:18:00 CST 2018
$ 

Cheers,
David.

Re: policy around 'wontfix' bug tag

[Thomas Schmitt]

Hi,

Mike Stone wrote:
> So it must be that "first tuesday" means
> the first tuesday in the month, but "second tuesday" sadly means the first
> tuesday plus one second because "second" has more than one meaning and I
> wanted the other one.

This illustrates the fundamental problem with natural english language,
in one miniature picture.


> Again, 20 years of dealing with people actually having trouble with this.

This explains your swift and sparse reaction on bug 389251.


Nicolas George wrote:
> Anyway, if you propose to remove the ability to write something like
> "2017-12-04 + 73 days", I veto as strongly as I can.

This illustrates the addiction problem of using exotic features.
We should not forget that the main job of "date" is to "print or set
the system date and time" - says the man page. 

But given the statements in this thread so far, nobody plans to change
anything with that situation. Any move could blast a mine.
So all working input formats are safe ... unless they only work by a bug
which needs to get fixed for some important reason.


Have a nice day :)

Thomas

Re: policy around 'wontfix' bug tag

[Michael Stone]

On Sun, Feb 04, 2018 at 05:00:14PM +0100, Nicolas George wrote:

Anyway, if you propose to remove the ability to write something like
"2017-12-04 + 73 days", I veto as strongly as I can.


The above is a very restricted subset of the date(1) grammar. Your 
confusion seems to stem from the fact that you're avoiding the
functionality that causes the problems. An obvious simple replacement 
grammar would be to accept ISO formatted timestamps, operators, and 
intervals (as you used above). That's actually probably too simple, as 
it would be nice to be able to specify things like the second tuesday of 
the month, or convert from a non-ISO timestamp. For that you'd need 
something more complex, but the right answer probably involves rigid 
keywords rather than trying to guess the context. Maybe something like 
'2017-12-04 + interval(73 days)' and 'relative(second tuesday of the 
month, month(2017-12-04))' and some way to use the + output specifiers 
as input specifiers. Anyway, if there was a simple solution someone 
would have implemented it by now. 

To get back to the original wontfix question, the bottom line is that 
the current implementation is known to have a lot of warts, you can't 
depend on it doing what you think it will do, and it's basically 
impossible to fix most of the problems without potentially breaking 
something that someone is using. So if someone finds something they 
think is stupid, the likely outcome is for there to be agreement that 
it's stupid but not for anything to change. As much as I'd like to see a 
new option with a better grammar, there's a real chicken-and-egg problem 
that makes it hard to get people interested in doing so.


Mike Stone

Re: policy around 'wontfix' bug tag

[Nicolas George]

Michael Stone (2018-02-04):
> Again, 20 years of dealing with people actually having trouble with this.
> I'm really not making this up.

Ok. Then please let me tell you that you have an observation bias: as (I
suppose) a maintainer of the package, you have to deal with people who
have a problem, but you never hear of people who manage to use the
natural syntax efficiently.

Anyway, if you propose to remove the ability to write something like
"2017-12-04 + 73 days", I veto as strongly as I can.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: policy around 'wontfix' bug tag

[Michael Stone]

On Sun, Feb 04, 2018 at 04:54:07PM +0100, Nicolas George wrote:

I hope you enjoy the warmth of the burning straw men. Good day.


Again, 20 years of dealing with people actually having trouble with 
this. I'm really not making this up.


Mike Stone

Re: policy around 'wontfix' bug tag

[Nicolas George]

Michael Stone (2018-02-04):
> Heck, let's try some natural language right now:

I hope you enjoy the warmth of the burning straw men. Good day.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: policy around 'wontfix' bug tag

[Michael Stone]

On Sun, Feb 04, 2018 at 04:04:34PM +0100, Nicolas George wrote:

All you describe is convenience for programmatic use. As I explained,
this parser is meant for interactive use. For interactive use,
flexibility and natural language are a convenience.


And you keep ignoring the fact that actual humans have trouble getting 
the results they want because as nice as the idea of natural language 
parsing is, it doesn't actually work reliably. If you have a couple of 
canned inputs you use routinely, you're not actually making use of the 
natural language parsing, you're using an obscure grammar that could 
easily be replaced by a different grammar.


Alternatively, instead of just repeating over and over that natural 
language parsing is convenient, please show the variety of date strings 
with which you make use of the full range of natural language parsing 
that has been implemented in date(1). Having watched people using 
date(1) for 20 years, I can say quite reliably that most people just 
find something that works and use it over and over--getting results in 
spite of the NLP, not because of it. Generally they find the thing that 
works by googling and copying, not by writing an arbitrary english 
sentence and seeing the expected results appear as if by magic.


Heck, let's try some natural language right now:


date

Sun Feb  4 10:30:42 EST 2018


date -d 'what was the date last week'

date: invalid date ‘what was the date last week’


date -d 'date last week'

date: invalid date ‘date last week’


date -d 'day last week'

Mon Jan 29 10:30:53 EST 2018

^^^ well, that's not they day it was last week. that's last week plus 
one day. explainable, not necessarily predictable.



date -d 'last week'

Sun Jan 28 10:31:33 EST 2018

^^^ well, you can get the date out of that, but IMO it's less "natural" 
and more "Og the cave man"



date -d 'month from now'

date: invalid date ‘month from now’

^^^ bummer, I really thought that might work


date -d 'month'

Sun Mar  4 10:33:21 EST 2018

^^^ Og the cave man strikes again


date -d '2 months ago'

Mon Dec  4 10:34:05 EST 2017

^^^ ooh, this one almost seems like natural language, I must be getting 
the hang of it



date -d '2 months and 2 days ago'

date: invalid date ‘2 months and 2 days ago’

^^^ whomp-whomp. what if I take out the "and"?


date -d '2 months 2 days ago'

Mon Apr  2 11:35:18 EDT 2018

^^^ WTF? Oh, it's 2 months in the future, minus 2 days. Wait, now I have 
another guess about what might work!



date -d '2 months ago 2 days ago'

Sat Dec  2 10:37:11 EST 2017

^^^ Totally natural!


date -d 'today - 2 months - 2 days'

Sat Dec  2 10:39:23 EST 2017

^^^ Hmm. Maybe it would be easier to just dump all the "ago" stuff and 
have a short list of keywords and operators? No, let's just keep going 
with this natural language stuff, it's much more convenient.



date -d 'first tuesday'

Tue Feb  6 00:00:00 EST 2018

date -d 'third tuesday'

Tue Feb 20 00:00:00 EST 2018

date -d 'second tuesday'

Tue Feb  6 00:00:01 EST 2018

^^^ Explainable, not predictable! So it must be that "first tuesday" 
means the first tuesday in the month, but "second tuesday" sadly means 
the first tuesday plus one second because "second" has more than one 
meaning and I wanted the other one. Oh well, at least I've figure it 
out.



date -d 'first thursday'

Thu Feb  8 00:00:00 EST 2018

^^^ WTF? Oh, so it isn't the first thursday in the month, it's the first 
thursday in the week. I guess that's useful. So "third tuesday" must 
have meant "the third tuesday in the week". That makes sense.


Mike Stone

Re: policy around 'wontfix' bug tag

[Nicolas George]

Michael Stone (2018-02-04):
> Well, it's not particularly convenient for people to have to constantly
> wonder why the parser isn't doing what they think it should do. I've been
> getting the questions and bug reports for 20 years, so trust me when I say
> that people have trouble predicting the output of a given input.


All you describe is convenience for programmatic use. As I explained,
this parser is meant for interactive use. For interactive use,
flexibility and natural language are a convenience.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: policy around 'wontfix' bug tag

[Michael Stone]

On Sun, Feb 04, 2018 at 02:27:00PM +0100, Nicolas George wrote:

Michael Stone (2018-02-04):

But a better parser would allow the same functionality, without being
confusing, inconsistent, and hard to maintain. So yes, I'll stand by
"complete misfeature".


Can you describe what you mean by "better parser" in more details?

Beware that the "same functionality" includes "same convenience".
Convenience is hard to achieve.


Well, it's not particularly convenient for people to have to constantly 
wonder why the parser isn't doing what they think it should do. I've 
been getting the questions and bug reports for 20 years, so trust me 
when I say that people have trouble predicting the output of a given 
input.


As far as "better parser" that means something that requires the input 
to be fully specified, and does not try to guess based on natural 
language parsing. For example, what does "last month" mean? What does it 
mean when you're on the 31st and the previous month didn't have a 31st? 
What date is 1/2? What time zone is "EST"? Making guesses seems 
"convenient" but when you hit corner cases and things break horribly, 
that's not convenient after all. Most date parsers address this by 
requiring a format specifier along with the input, so you can say 
something like "parse '1/2' assuming the input is 
numericday/numericmonth". Is it less "convenient" to have to specify the 
format? Maybe, but it's also a heck of a lot more reliable. Someone else 
pointed out postgresql's date parser, which lets you do things like 
specify a date and then add something like "interval '1 day'". 
Specifying the fact that a particular string is an interval makes the 
parsing much more regular than trying to pull the interval out of 
natural language. At one point date would appear to properly parse 
ISO8601 input (-mm-ddTHH:MM:SS) but it interpreted the "T" as a 
timezone specifier instead of the ISO8601 delimiter. (Compare output 
with -mm-ddUHH:MM:SS or -mm-ddSHH:MM:SS.) Why would it ever have 
been "convenient" to put a alphabet character timezone specifier after 
the date and before the time? Who knows, but the natural language parser 
was doing its best to guess a meaning for the input. That particular 
issue was fixed, but how you can tell whether you're using a version 
that works the old way or the new way?  (Answer: you can't easily do so. 
If you had to specify a format it would be easier to hard fail if trying 
to use a format that wasn't understood rather than soft fail and produce 
random output.) Is it "convenient" that there's a natural language 
parser that only understands english?  Maybe, if you speak english?


Mike Stone

Re: policy around 'wontfix' bug tag

[Nicolas George]

Thomas Schmitt (2018-02-04):
> And what should human or machine think of my mail client's idea about
> when you sent your mail ?
> 
>Tomorrow   Richard Hector  Re: policy around 'wontfix' bug tag 

That it should learn to parse timezones and take them into account. The
date in Richard's mail is fine.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: policy around 'wontfix' bug tag

[Richard Hector]

On 05/02/18 02:39, Thomas Schmitt wrote:
> And what should human or machine think of my mail client's idea about
> when you sent your mail ?
> 
>Tomorrow   Richard Hector  Re: policy around 'wontfix' bug tag 

Ha! That I'm in NZ, of course. And I'm up too late. I never see that,
because we pretty much lead the world here :-)

Richard



signature.asc
Description: OpenPGP digital signature

Re: policy around 'wontfix' bug tag

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Feb 04, 2018 at 08:22:23AM -0500, Michael Stone wrote:

[...]

> But a better parser would allow the same functionality, without
> being  confusing, inconsistent, and hard to maintain. So
> yes, I'll stand by   "complete misfeature".

While we do agree that datetime input formats are, at times,
ambiguous and generally a mess, generic datetime parsing
functionality *is* useful, and *can* be done (albeit sometimes
needing some recourse to "ambient information", which might
be provided by locale, e.g.).

Thus I do agree with your statement "it's messy", less so
with "it's useless" or "can't be done".

PostgreSQL[1] gives a good working example of an implementation
which is useful.

But since `date' has to cater for backward compatibility, the
constraints are harder, I agree.

Cheers

[1] 
https://www.postgresql.org/docs/9.1/static/datatype-datetime.html#DATATYPE-DATETIME-INPUT
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlp3DdcACgkQBcgs9XrR2kYVkACdGVS1KtyDauTFi4S/tA97P6WG
VIcAoIBuVtnGSURj7v7yho6aF1wmVCTE
=WAbh
-END PGP SIGNATURE-

Re: policy around 'wontfix' bug tag

[Thomas Schmitt]

Hi,

Richard Hector wrote:
> Incidentally, the gnu 'Date input formats' link above does talk about
> only accepting English names for days and months, but doesn't say
> anything about the ordering of day and month (except, under 'General
> date syntax', saying that 'Order of the items is immaterial' ...)

The preamble quote tells a lot about the disillusion of the writer
of "Date input formats".

The disease is much less obvious in german language, though. There you
need to go down to quarter hours and regional habits to get truely ambigous.
In english i sometimes have to riddle whether a date is Day/Month/Year or
Month/Day/Year. Whatever the rules are, writers seem confused about them.
Possibly because so many of us aliens are around.

And what should human or machine think of my mail client's idea about
when you sent your mail ?

   Tomorrow   Richard Hector  Re: policy around 'wontfix' bug tag 


Have a nice day :)

Thomas

Re: policy around 'wontfix' bug tag

[Nicolas George]

Michael Stone (2018-02-04):
> But a better parser would allow the same functionality, without being
> confusing, inconsistent, and hard to maintain. So yes, I'll stand by
> "complete misfeature".

Can you describe what you mean by "better parser" in more details?

Beware that the "same functionality" includes "same convenience".
Convenience is hard to achieve.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: policy around 'wontfix' bug tag

[Michael Stone]

On Mon, Feb 05, 2018 at 12:48:45AM +1300, Richard Hector wrote:

In which case, it should refuse to accept '4/2/2018' at all, right?


It can't, that would break working scripts. This is the heart of the 
problem: we know the parser is horrible, confusing, and irregular, but 
any attempt to change it will break lots of stuff that depends on the 
current brokenness.


On Sun, Feb 04, 2018 at 01:32:18PM +0100, Nicolas George wrote:

The date parser is quite convenient, I use it frequently for small dates
calculations, and I am not alone in that at all. That disproves the fact
that it is a "complete misfeature".


But a better parser would allow the same functionality, without being  
confusing, inconsistent, and hard to maintain. So yes, I'll stand by   
"complete misfeature". 


Mike Stone

Re: policy around 'wontfix' bug tag

[Henrique de Moraes Holschuh]

On Mon, 05 Feb 2018, Richard Hector wrote:
> On 05/02/18 00:43, Nicolas George wrote:
> > Richard Hector (2018-02-05):
> >> #389251 (coreutils: date's -d switch doesn't honour locale) - it's quite
> >> an old one. But I found another instance in which the same claim applies:
> >>
> >> richard@zircon:~$ date -d '4/2/2018'
> >> Mon Apr  2 00:00:00 NZST 2018
> >>
> >> In my NZ locale, that date should be interpreted as 4 Feb.
> > 
> > I would have to agree with coreutils: localizing parsing is an
> > aberration that should never have been implemented, and it is a good
> > thing that we progressively get rid of it.
> > 
> > Anecdote: more than 15 years ago, with some locales, if you were to call
> > gtk_init() from the OCaml interactive interpreter, and then issue "let
> > pi = 3.14;;", you would get "pi = 3.0", because gtk_init() would have
> > initialized locales and made the decimal separator a comma.
> > 
> > Never ever use "DD/MM/", "DD-MM-", "MM-DD-" nor
> > "MM/DD/". If your output is intended for humans, print your month
> > names; if your output is intended for computers, use the only logical
> > order: -MM-DD. It is standardized and understood by coreutils.
> 
> In which case, it should refuse to accept '4/2/2018' at all, right?

>From day one, yes.

But it didn't, and that Utterly Bad Pattern became an stable ABI which
you cannot just change due to the breakage it would cause on scripts
around the world.

-- 
  Henrique Holschuh

Re: policy around 'wontfix' bug tag

[Richard Hector]

On 05/02/18 01:44, Nicolas George wrote:
>> PS - please don't cc me; I'm on the list.
> Done this once, but I cannot promise I will think of it later. Document
> your preference in your mail mail header, the standard way, so that it
> is automatic and works for everybody, just like I did. Too bad the list
> software is not properly configured to do that automatically.

My preference is for any personal replies addressed to me to go to me,
and I'd use the Reply-to header (as intended) if I needed it to go
somewhere else. But replies to the list should go to the list (only)
(unless otherwise requested), as per list policy.

But I think I've seen you argue this before, so I'm happy to drop it now :-)

Richard



signature.asc
Description: OpenPGP digital signature

Re: policy around 'wontfix' bug tag

[Nicolas George]

Richard Hector (2018-02-05):
> Now that you mention it ... ls was where I started this adventure,
> reading coreutils bugs :-)
> 
> And you mention SI prefixes - IMHO, the output of ls should be extended
> to actually show 'GiB' rather than 'G' where that is what is meant.
> Assumptions that the user 'knows what it means' are horrible things -
> even when documented in the man page.

I do not agree. Screen real estate is expansive, I would not want to see
the space of two characters be wasted for the benefit of people who
cannot be bothered to read a documentation.

> PS - please don't cc me; I'm on the list.

Done this once, but I cannot promise I will think of it later. Document
your preference in your mail mail header, the standard way, so that it
is automatic and works for everybody, just like I did. Too bad the list
software is not properly configured to do that automatically.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: policy around 'wontfix' bug tag

[Richard Hector]

On 05/02/18 01:32, Nicolas George wrote:
> Richard Hector (2018-02-05):
>> Actually, a good(ish) explanation is provided in a later bug, #729952:
>>
>> --8<--
>> The date parsing feature exists in Debian only for compatibility with
>> upstream. It is a complete misfeature, and I would prefer that it didn't
>> exist at all. In an ideal world the entire idea of trying to utilize a
>> natural language parser would be scrapped in favor of a simple and
>> regular grammar. Unfortunately, it is what it is. The only way to use
>> the feature is to experiment until you find something that does what you
>> want. The corollary to that is that nothing can be changed, because
>> doing so would break existing scripts that were tweaked to perform
>> correctly using the current implementation.
> 
> This statement mixes good and bad.
> 
> The date parser is quite convenient, I use it frequently for small dates
> calculations, and I am not alone in that at all. That disproves the fact
> that it is a "complete misfeature".
> 
> The truth is that it is a badly-used feature. It is the same as the
> pretty-printed output of ls, with colors, columns, type suffixes, SI
> prefixes, etc.: it makes the output more readable for a human, less
> readable for a computer. It is good for interactive use, bad for script
> use. For script use, there are other tools, depending on the task.

Now that you mention it ... ls was where I started this adventure,
reading coreutils bugs :-)

And you mention SI prefixes - IMHO, the output of ls should be extended
to actually show 'GiB' rather than 'G' where that is what is meant.
Assumptions that the user 'knows what it means' are horrible things -
even when documented in the man page.

Richard
PS - please don't cc me; I'm on the list.



signature.asc
Description: OpenPGP digital signature

Re: policy around 'wontfix' bug tag

[Nicolas George]

Richard Hector (2018-02-05):
> Actually, a good(ish) explanation is provided in a later bug, #729952:
> 
> --8<--
> The date parsing feature exists in Debian only for compatibility with
> upstream. It is a complete misfeature, and I would prefer that it didn't
> exist at all. In an ideal world the entire idea of trying to utilize a
> natural language parser would be scrapped in favor of a simple and
> regular grammar. Unfortunately, it is what it is. The only way to use
> the feature is to experiment until you find something that does what you
> want. The corollary to that is that nothing can be changed, because
> doing so would break existing scripts that were tweaked to perform
> correctly using the current implementation.

This statement mixes good and bad.

The date parser is quite convenient, I use it frequently for small dates
calculations, and I am not alone in that at all. That disproves the fact
that it is a "complete misfeature".

The truth is that it is a badly-used feature. It is the same as the
pretty-printed output of ls, with colors, columns, type suffixes, SI
prefixes, etc.: it makes the output more readable for a human, less
readable for a computer. It is good for interactive use, bad for script
use. For script use, there are other tools, depending on the task.

Do not blame the feature, blame the people who misuse it.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: policy around 'wontfix' bug tag

[Richard Hector]

On 05/02/18 01:13, Thomas Schmitt wrote:
> Hi,
> 
> Richard Hector wrote:
>> #389251 (coreutils: date's -d switch doesn't honour locale) - it's quite
>> an old one. But I found another instance in which the same claim applies:
> 
> Its age makes it hard to conclude nowadays' habits with newly submitted bugs.
> 
> The topic looks as promising for Debian bug report success as would be
> a report about the Linux kernel. I.e. nearly zero.
> 
> Upstream looks like the problem is known and no fix can be expected soon:
> 
>   
> https://www.gnu.org/software/coreutils/manual/html_node/Options-for-date.html
>   "
>   ‘-d datestr’
>   ‘--date=datestr’
>  Display the date and time specified in datestr instead of the current
>  date and time. datestr can be in almost any common format.
>  [...]
>  Note: input currently must be in locale independent format.
>  E.g., the LC_TIME=C below is needed to print back the correct date in
>  many locales:
>date -d "$(LC_TIME=C date)"
>  See Date input formats.
>  [ 
> https://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html
>  ]
>   "
> 
> The google results of "locale input" and "linux locale input" make me
> think that there is no general input support with our locales.
> Maybe some particular programs take the environment variable settings
> as hint for own input interpreters. But in general our localization seems
> to be restricted to output texts.
> 
> Adding to the bug report a link to above upstream documentation would
> have been a friendly gesture to the bug reporter.
> The bug was not closed, though. So "wontfix" does not mean "rejected"
> or "invalid", but rather expresses the realistic expectation of the sender.

Thanks Thomas - you can always be counted on to provide calm, rational
input :-)

Incidentally, the gnu 'Date input formats' link above does talk about
only accepting English names for days and months, but doesn't say
anything about the ordering of day and month (except, under 'General
date syntax', saying that 'Order of the items is immaterial' ...)

Cheers,
Richard



signature.asc
Description: OpenPGP digital signature

Re: policy around 'wontfix' bug tag

[Thomas Schmitt]

Hi,

Richard Hector wrote:
> #389251 (coreutils: date's -d switch doesn't honour locale) - it's quite
> an old one. But I found another instance in which the same claim applies:

Its age makes it hard to conclude nowadays' habits with newly submitted bugs.

The topic looks as promising for Debian bug report success as would be
a report about the Linux kernel. I.e. nearly zero.

Upstream looks like the problem is known and no fix can be expected soon:

  https://www.gnu.org/software/coreutils/manual/html_node/Options-for-date.html
  "
  ‘-d datestr’
  ‘--date=datestr’
 Display the date and time specified in datestr instead of the current
 date and time. datestr can be in almost any common format.
 [...]
 Note: input currently must be in locale independent format.
 E.g., the LC_TIME=C below is needed to print back the correct date in
 many locales:
   date -d "$(LC_TIME=C date)"
 See Date input formats.
 [ 
https://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html 
]
  "

The google results of "locale input" and "linux locale input" make me
think that there is no general input support with our locales.
Maybe some particular programs take the environment variable settings
as hint for own input interpreters. But in general our localization seems
to be restricted to output texts.

Adding to the bug report a link to above upstream documentation would
have been a friendly gesture to the bug reporter.
The bug was not closed, though. So "wontfix" does not mean "rejected"
or "invalid", but rather expresses the realistic expectation of the sender.


Have a nice day :)

Thomas

Re: policy around 'wontfix' bug tag

[Richard Hector]

On 05/02/18 00:30, Richard Hector wrote:
> On 05/02/18 00:16, Thomas Schmitt wrote:
>> Hi,
>>
>> Richard Hector wrote:
>>> When a maintainer tags a bug report with 'wontfix', is there not an
>>> expectation that they will say why?
>>
>> Obviously the Debian Developers have much freedom how to act. At least
>> if it is about packaging and bug report processing.
>>
>> As for Debian policy, in this case it is probably written in
>>   https://www.debian.org/Bugs/Developer#tags
>> which says:
>>   "wontfix
>>This bug won't be fixed. Possibly because this is a choice between two
>>arbitrary ways of doing things and the maintainer and submitter prefer
>>different ways of doing things, possibly because changing the behaviour
>>will cause other, worse, problems for others, or possibly for other
>>reasons."
>>
>> If i wondered about such a tag without explanation and felt affected by
>> the bug, then i'd mail to the bug report asking for an explanation.
>>
>>
>>> I was just reading a bug report that seemed valid
>>
>> Mind to share its number ?
> 
> #389251 (coreutils: date's -d switch doesn't honour locale) - it's quite
> an old one. But I found another instance in which the same claim applies:
> 
> richard@zircon:~$ date -d '4/2/2018'
> Mon Apr  2 00:00:00 NZST 2018
> 
> In my NZ locale, that date should be interpreted as 4 Feb.

Actually, a good(ish) explanation is provided in a later bug, #729952:

--8<--
The date parsing feature exists in Debian only for compatibility with
upstream. It is a complete misfeature, and I would prefer that it didn't
exist at all. In an ideal world the entire idea of trying to utilize a
natural language parser would be scrapped in favor of a simple and
regular grammar. Unfortunately, it is what it is. The only way to use
the feature is to experiment until you find something that does what you
want. The corollary to that is that nothing can be changed, because
doing so would break existing scripts that were tweaked to perform
correctly using the current implementation.

Mike Stone
--8<--

Richard



signature.asc
Description: OpenPGP digital signature

Re: policy around 'wontfix' bug tag

[Richard Hector]

On 05/02/18 00:43, Nicolas George wrote:
> Richard Hector (2018-02-05):
>> #389251 (coreutils: date's -d switch doesn't honour locale) - it's quite
>> an old one. But I found another instance in which the same claim applies:
>>
>> richard@zircon:~$ date -d '4/2/2018'
>> Mon Apr  2 00:00:00 NZST 2018
>>
>> In my NZ locale, that date should be interpreted as 4 Feb.
> 
> I would have to agree with coreutils: localizing parsing is an
> aberration that should never have been implemented, and it is a good
> thing that we progressively get rid of it.
> 
> Anecdote: more than 15 years ago, with some locales, if you were to call
> gtk_init() from the OCaml interactive interpreter, and then issue "let
> pi = 3.14;;", you would get "pi = 3.0", because gtk_init() would have
> initialized locales and made the decimal separator a comma.
> 
> Never ever use "DD/MM/", "DD-MM-", "MM-DD-" nor
> "MM/DD/". If your output is intended for humans, print your month
> names; if your output is intended for computers, use the only logical
> order: -MM-DD. It is standardized and understood by coreutils.

In which case, it should refuse to accept '4/2/2018' at all, right?

I almost always uses -MM-DD, except when filling in a form with
spaces provided - in which case I'll write (eg) 'Feb' in the month
space, to avoid ambiguity.

Richard



signature.asc
Description: OpenPGP digital signature

Re: policy around 'wontfix' bug tag

[Nicolas George]

Richard Hector (2018-02-05):
> #389251 (coreutils: date's -d switch doesn't honour locale) - it's quite
> an old one. But I found another instance in which the same claim applies:
> 
> richard@zircon:~$ date -d '4/2/2018'
> Mon Apr  2 00:00:00 NZST 2018
> 
> In my NZ locale, that date should be interpreted as 4 Feb.

I would have to agree with coreutils: localizing parsing is an
aberration that should never have been implemented, and it is a good
thing that we progressively get rid of it.

Anecdote: more than 15 years ago, with some locales, if you were to call
gtk_init() from the OCaml interactive interpreter, and then issue "let
pi = 3.14;;", you would get "pi = 3.0", because gtk_init() would have
initialized locales and made the decimal separator a comma.

Never ever use "DD/MM/", "DD-MM-", "MM-DD-" nor
"MM/DD/". If your output is intended for humans, print your month
names; if your output is intended for computers, use the only logical
order: -MM-DD. It is standardized and understood by coreutils.

And if you need input from the user, provide a higher-level interface.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: policy around 'wontfix' bug tag

[Richard Hector]

On 05/02/18 00:16, Thomas Schmitt wrote:
> Hi,
> 
> Richard Hector wrote:
>> When a maintainer tags a bug report with 'wontfix', is there not an
>> expectation that they will say why?
> 
> Obviously the Debian Developers have much freedom how to act. At least
> if it is about packaging and bug report processing.
> 
> As for Debian policy, in this case it is probably written in
>   https://www.debian.org/Bugs/Developer#tags
> which says:
>   "wontfix
>This bug won't be fixed. Possibly because this is a choice between two
>arbitrary ways of doing things and the maintainer and submitter prefer
>different ways of doing things, possibly because changing the behaviour
>will cause other, worse, problems for others, or possibly for other
>reasons."
> 
> If i wondered about such a tag without explanation and felt affected by
> the bug, then i'd mail to the bug report asking for an explanation.
> 
> 
>> I was just reading a bug report that seemed valid
> 
> Mind to share its number ?

#389251 (coreutils: date's -d switch doesn't honour locale) - it's quite
an old one. But I found another instance in which the same claim applies:

richard@zircon:~$ date -d '4/2/2018'
Mon Apr  2 00:00:00 NZST 2018

In my NZ locale, that date should be interpreted as 4 Feb.

Richard



signature.asc
Description: OpenPGP digital signature

Re: policy around 'wontfix' bug tag

[Thomas Schmitt]

Hi,

Richard Hector wrote:
> When a maintainer tags a bug report with 'wontfix', is there not an
> expectation that they will say why?

Obviously the Debian Developers have much freedom how to act. At least
if it is about packaging and bug report processing.

As for Debian policy, in this case it is probably written in
  https://www.debian.org/Bugs/Developer#tags
which says:
  "wontfix
   This bug won't be fixed. Possibly because this is a choice between two
   arbitrary ways of doing things and the maintainer and submitter prefer
   different ways of doing things, possibly because changing the behaviour
   will cause other, worse, problems for others, or possibly for other
   reasons."

If i wondered about such a tag without explanation and felt affected by
the bug, then i'd mail to the bug report asking for an explanation.


> I was just reading a bug report that seemed valid

Mind to share its number ?


Have a nice day :)

Thomas

policy around 'wontfix' bug tag

[Richard Hector]

Hi all,

This might not be the most useful list, but I'm not subscribed to -devel
and don't want to jump in there without good reason.

When a maintainer tags a bug report with 'wontfix', is there not an
expectation that they will say why?

I was just reading a bug report that seemed valid (if correct; I
couldn't actually test it easily) but was tagged 'wontfix' with no
explanation.

In that case the bug if anything should have been forwarded upstream,
but tagging 'wontfix' with no reason seems a little rude?

Cheers,
Richard



signature.asc
Description: OpenPGP digital signature

Re: html page for bug report

[Pétùr]

Just to let you know I finally opt for a simple html page created with
org-mode. I use the checkboxes (org-mode can export checkboxes in proper
html) to allow visitors to check (ie mark a bug/feature as
fixed/implemented.

Re: history issue - bug?

[Felipe Salvador]

On Sun, Jan 14, 2018 at 06:24:27PM +0100, Felipe Salvador wrote:
> On Sun, Jan 14, 2018 at 02:07:01PM +0100, Hans wrote:
> > Hi folks, 
> > 
> > try this:
> > 
> > 1. login as normal user
> > 
> > 2. become root with "su -"
> > 
> > 3. delete history with "history -c"
> 
> Then run "history -w" to "write the current history to the history
> file"

Maybe you could fill a bug report in order to ask if it is possible
change the history behaviour about -c and -w switches, actually it
doesn't accept this combination, you cannot use

$history -c -w  
or
    $history -cw

You have to run separately

$history -c
AND
$history -w

Though I don't think this is a bug.


Regards
-- 
Felipe Salvador

Re: Bug Report

[davidson]

On Tue, 16 Jan 2018, songbird wrote:


David Wright wrote:
...


Un-trimming some evidence:


On Mon 15 Jan 2018 at 23:27:30 (-0500), James Vibber wrote:

[...]

Unpacking libc6:armhf (2.26-2) over (2.19-18+deb8u10) ...


Would it be better to upgrade jessie???stretch before stretch???buster?


 if that is what OP is doing,


Judging by the libc6 versions, that is exactly what it looks like.


then yes, skipping major versions has never been officially
supported.

 at that stage it is often much more time efficient
to re install from recent images.


 songbird

Re: Bug Report

[songbird]

David Wright wrote:
...
> Would it be better to upgrade jessie→stretch before stretch→buster?

  if that is what OP is doing, then yes, skipping
major versions has never been officially supported.

  at that stage it is often much more time efficient 
to re install from recent images.


  songbird

Re: Fwd: Bug Report

[Greg Wooledge]

> >   WARNING: The following essential packages will be removed.
> >   This should NOT be done unless you know exactly what you are doing!
> >     apt libapt-pkg4.12 (due to apt) libc6 (due to apt) libgcc1 (due to apt) 
> > libstdc++6 (due to apt) gnupg (due to apt)
[...]

On Tue, Jan 16, 2018 at 01:31:39PM +, Darac Marjal wrote:
> Thirdly, (and I GUESS that this is why you're trying to report a bug), do
> YOU see a differenve between:
> 
>   Yes, do as I say!
> 
> and
> 
>   yes,do as I say!
> 
> ?

It's good that he failed to type it correctly.  His system would NOT
have survived had he confirmed this removal.

Re: Fwd: Bug Report

[Darac Marjal]

On Mon, Jan 15, 2018 at 11:31:02PM -0500, James Vibber wrote:

  -- Forwarded message --
  From: "James Vibber" <[1]jvibbe...@gmail.com>
  Date: Jan 15, 2018 10:54 PM
  Subject: Bug Report
  To: <[2]deb...@gmail.com>
  Cc:

  WARNING: The following essential packages will be removed.
  This should NOT be done unless you know exactly what you are doing!
    apt libapt-pkg4.12 (due to apt) libc6 (due to apt) libgcc1 (due to apt) 
libstdc++6 (due to apt) gnupg (due to apt)
  base-passwd libdebconfclient0 (due to base-passwd) bash debianutils (due to 
bash) dash (due to
    bash) libncurses5 (due to bash) libtinfo5 (due to bash) bsdutils 
libsystemd0 (due to bsdutils) coreutils libacl1 (due to
  coreutils) libattr1 (due to coreutils) libselinux1 (due to coreutils) dpkg 
(due to dash)
    diffutils libbz2-1.0 (due to dpkg) liblzma5 (due to dpkg) zlib1g (due to 
dpkg) tar (due to dpkg) e2fsprogs e2fslibs (due
  to e2fsprogs) libblkid1 (due to e2fsprogs) libcomerr2 (due to e2fsprogs) 
libss2 (due to
    e2fsprogs) libuuid1 (due to e2fsprogs) util-linux (due to e2fsprogs) 
findutils grep libpcre3 (due to grep) gzip hostname
  init systemd-sysv (due to init) init-system-helpers perl-base (due to
    init-system-helpers) libc-bin login libaudit1 (due to login) libpam0g (due 
to login) libpam-runtime (due to login)
  libpam-modules (due to login) mount libmount1 (due to mount) libsmartcols1 
(due to mount)
    ncurses-bin sed sysvinit-utils startpar (due to sysvinit-utils) initscripts 
(due to util-linux) tzdata (due to util-linux)
  libslang2 (due to util-linux)
  43 upgraded, 33 newly installed, 1458 to remove and 172 not upgraded.
  4 not fully installed or removed.
  Need to get 29.6 MB/41.1 MB of archives.
  After this operation, 2407 MB disk space will be freed.
  You are about to do something potentially harmful.
  To continue type in the phrase 'Yes, do as I say!'
  ?] yes,do as I say!
  Abort.
  root@loc


Firstly, it's normal to accompany a bug report with some narrative. An 
isolated error message is not always useful to a developer. Adding "I 
was trying to install firefox and apt wanted to delete every other 
package' gives the developer some context. The above is akin to taking 
your car into a garage and pointed at the "Check Engine" light


Secondly, I presume you're sending the message to debian-user@l.d.o 
because you don't know which package to report the bug against. In my 
opinion, that depends on what, exactly, you're complaining about. Are 
you complaining that making some change to packages caused apt to try to 
remove essential packages (but if it was that, you'd have told us what 
changes you were trying to make, any why you were willing to remove 
them)?


Thirdly, (and I GUESS that this is why you're trying to report a bug), 
do YOU see a differenve between:


Yes, do as I say!

and

yes,do as I say!

?



References

  Visible links
  1. mailto:jvibbe...@gmail.com
  2. mailto:deb...@gmail.com


--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Bug Report

[David Wright]

On Mon 15 Jan 2018 at 23:27:30 (-0500), James Vibber wrote:
> http://ftp.debian.org/debian/ buster/main zsh-common all 5.4.2-3 [3529 kB]
> Fetched 11.7 MB in 13s (846 kB/s)
> Extracting templates from packages: 100%
> Preconfiguring packages ...
> cat: /sys/bus/usb/devices/*:*/bInterfaceClass: No such file or directory
> cat: /sys/bus/usb/devices/*:*/bInterfaceSubClass: No such file or directory
> cat: /sys/bus/usb/devices/*:*/bInterfaceProtocol: No such file or directory
> (Reading database ... 146452 files and directories currently installed.)
> Preparing to unpack .../libc6_2.26-2_armhf.deb ...
> Checking for services that may need to be restarted...
> Checking init scripts...
> Failed to read /proc/cmdline. Ignoring: Permission denied
> Unpacking libc6:armhf (2.26-2) over (2.19-18+deb8u10) ...

Would it be better to upgrade jessie→stretch before stretch→buster?

> dpkg: warning: subprocess old post-removal script was killed by signal
> (Segmentation fault)
> dpkg: trying script from the new package instead ...
> dpkg: error processing archive /var/cache/apt/archives/libc6_2.26-2_armhf.deb
> (--unpack):
> subprocess new post-removal script was killed by signal (Segmentation fault)
> dpkg: error while cleaning up:
> subprocess installed pre-installation script was killed by signal
> (Segmentation fault)
> Processing triggers for libc-bin (2.19-18+deb8u10) ...
> Error connecting: Could not connect: Connection refused
> E: Sub-process /usr/bin/dpkg return

Cheers,
David.

Fwd: Bug Report

[James Vibber]

-- Forwarded message --
From: "James Vibber" 
Date: Jan 15, 2018 10:54 PM
Subject: Bug Report
To: 
Cc:


WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  apt libapt-pkg4.12 (due to apt) libc6 (due to apt) libgcc1 (due to apt)
libstdc++6 (due to apt) gnupg (due to apt) base-passwd libdebconfclient0
(due to base-passwd) bash debianutils (due to bash) dash (due to
  bash) libncurses5 (due to bash) libtinfo5 (due to bash) bsdutils
libsystemd0 (due to bsdutils) coreutils libacl1 (due to coreutils) libattr1
(due to coreutils) libselinux1 (due to coreutils) dpkg (due to dash)
  diffutils libbz2-1.0 (due to dpkg) liblzma5 (due to dpkg) zlib1g (due to
dpkg) tar (due to dpkg) e2fsprogs e2fslibs (due to e2fsprogs) libblkid1
(due to e2fsprogs) libcomerr2 (due to e2fsprogs) libss2 (due to
  e2fsprogs) libuuid1 (due to e2fsprogs) util-linux (due to e2fsprogs)
findutils grep libpcre3 (due to grep) gzip hostname init systemd-sysv (due
to init) init-system-helpers perl-base (due to
  init-system-helpers) libc-bin login libaudit1 (due to login) libpam0g
(due to login) libpam-runtime (due to login) libpam-modules (due to login)
mount libmount1 (due to mount) libsmartcols1 (due to mount)
  ncurses-bin sed sysvinit-utils startpar (due to sysvinit-utils)
initscripts (due to util-linux) tzdata (due to util-linux) libslang2 (due
to util-linux)
43 upgraded, 33 newly installed, 1458 to remove and 172 not upgraded.
4 not fully installed or removed.
Need to get 29.6 MB/41.1 MB of archives.
After this operation, 2407 MB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
?] yes,do as I say!
Abort.
root@loc

Fwd: Bug Report

[James Vibber]

-- Forwarded message --
From: "James Vibber" 
Date: Jan 15, 2018 10:52 PM
Subject: Bug Report
To: 
Cc:

kage binutils-arm-linux-gnueabihf is not configured yet.

dpkg: error processing package binutils (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
libc6:armhf
libbinutils:armhf
binutils-arm-linux-gnueabihf
binutils
Error connecting: Could not connect: Connection refused
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@localhost:/#

Bug Report

[James Vibber]

http://ftp.debian.org/debian/ buster/main zsh-common all 5.4.2-3 [3529 kB]
Fetched 11.7 MB in 13s (846 kB/s)
Extracting templates from packages: 100%
Preconfiguring packages ...
cat: /sys/bus/usb/devices/*:*/bInterfaceClass: No such file or directory
cat: /sys/bus/usb/devices/*:*/bInterfaceSubClass: No such file or directory
cat: /sys/bus/usb/devices/*:*/bInterfaceProtocol: No such file or directory
(Reading database ... 146452 files and directories currently installed.)
Preparing to unpack .../libc6_2.26-2_armhf.deb ...
Checking for services that may need to be restarted...
Checking init scripts...
Failed to read /proc/cmdline. Ignoring: Permission denied
Unpacking libc6:armhf (2.26-2) over (2.19-18+deb8u10) ...
dpkg: warning: subprocess old post-removal script was killed by signal
(Segmentation fault)
dpkg: trying script from the new package instead ...
dpkg: error processing archive /var/cache/apt/archives/libc6_2.26-2_armhf.deb
(--unpack):
subprocess new post-removal script was killed by signal (Segmentation fault)
dpkg: error while cleaning up:
subprocess installed pre-installation script was killed by signal
(Segmentation fault)
Processing triggers for libc-bin (2.19-18+deb8u10) ...
Error connecting: Could not connect: Connection refused
E: Sub-process /usr/bin/dpkg return

Re: history issue - bug?

[davidson]

On Sun, 14 Jan 2018, Hans wrote:


Am Sonntag, 14. Januar 2018, 08:41:21 CET schrieb David Wright:
Hi David,

thanks for enlightening me. I always though, that "history -c" would
clear all the history and its files as the help file says:

-cclear the history list by deleting all of the entries

So IMO this should delete all related history files, even
bash_history.


"Even" bash_history? Besides .bash_history, what other files did you
have in mind?

If "history -c" deleted any file at all, the documentation would need
to be changed to reflect that fact. At present, the documentation is
accurate.

A list has entries, and if you delete all the entries, that means you
now have an empty list. It certainly does NOT mean that you have
thereby nuked any and all files to which (the at-most $HISTSIZE length
tails of) previous iterations of that list have been saved.

I suspect that you must be distressed to discover a workflow you had
relied on does not in fact accomplish what you had long thought it
accomplished, because you had conceptually conflated two distinct
entities:

 * your shell *session's* command history *list*

versus

 * your *account's* command history *file*.

Speaking from repeated experience, it does indeed suck to learn that
your beliefs about a trusted tool's behavior have been mistaken for a
long time.

If this is the case, you have my condolences.

But you also have my congratulations, and perhaps you will agree that
finding out you were wrong is still far better than the alternative,
which is to remain forever blissfully mistaken.


And as far as I remember, this did it do in former times.

In my eyes this is a security hole, as someone, who gaines root
somehow (what already is bad eneough) might get more informations of
commands, root did in the past.


You'd like to do without the convenience of a persistent command
history file for root shells.

Since it is your concern to ensure that you don't leave behind shell
command history in a history file:

 1. Did you see Felipe Salvador's suggested addition (elsewhere in
this thread) to your original workflow? Looked pretty slick to me.

 2. The shell variables HISTFILE and HISTFILESIZE are documented in
the bash man page. Set HISTFILESIZE to 0, or unset HISTFILE.
(Since for bash login shells my /root/.profile sources ~/.bashrc,
my understanding is that it would suffice in my case to set/unset
these in /root/.bashrc to the appropriate value.)

If you know you won't want persistent command history on a given
account, this seems a reasonably reliable way to arrange that you
don't get one.

 3. Also in the bash man page is documentation of the shell variables
HISTIGNORE and HISTCONTROL.

 * HISTIGNORE is a colon-separated list of patterns that match
   commands you wish to omit from the history list altogether.

 * HISTCONTROL is a colon-separated list. If one of its elements
   is 'ignorespace', then any command line that begins with a
   space will be omitted from the history list.

NB: Subsequent lines after the first line, of a multi-line
command, are stored in the history list regardless of HISTIGNORE
and HISTCONTROL.

 4. If I remember correctly mksh, the MirBSD Korn shell, by default
writes to no command history file at all, even for a regular user
account. (Though this can of course be configured to suit user
preference.)  Maybe its design would please you better than bash
in other ways, as well.


As I said, history -c should delete ALL traces of history, just as
the help files tells, shouldn't it?


Just FYI, the documentation on bash builtins you get from "help
[builtin]" is intentionally terse, and provides far less contextual
information, than the information available in the bash man page.


As you confirmed, it does not and you also confirmed, that this is
normal behaviour.

In this case, I recommend this as a failure-by-design.

Again, thanks for your clearence, I will file a bug report.


Of course you will do what seems best to you.

But it seems to me that studying the bash man page, to see what else
you might have wrongly assumed, might make better use of your time.

I base this advice this on two rules of thumb:

 1. Better sooner than later.

 2. The bash man page is dense with useful information.

Good luck with your stuff.

--

"We’re not arguing for censorship, we’re arguing just take it off the
page, put it somewhere else." -- Eric Schmidt

Re: history issue - bug?

[David Wright]

On Sun 14 Jan 2018 at 12:59:55 (-0500), rhkra...@gmail.com wrote:
> On Sunday, January 14, 2018 12:14:47 PM bw wrote:
> > On Sun, 14 Jan 2018, Hans wrote:
> > > Am Sonntag, 14. Januar 2018, 08:41:21 CET schrieb David Wright:
> > > Hi David,
> > > 
> > > thanks for enlightening me. I always though, that "history -c" would
> > > clear all the history and its files as the help file says:
> > > 
> > > -cclear the history list by deleting all of the entries
> > > 
> > > So IMO this should delete all related history files, even bash_history.
> > 
> > Shouldn't it do what it says it will do?
> > 
> > It says "clear... the list" it does not say delete files.  I can't answer
> > the question about how long it has been this way, but I'm sure it is
> > documented, so maybe look that up before fiing a bug about it?
> 
> I don't know if I want to comment or not.  To me, it takes a fairly savvy 
> user 
> to recognize that list and file are not synonymous--for many casual users 
> (including me, and I consider myself generally as something more than just a 
> casual user), that documentation is not sufficient.

[…]

>  (Of course, I haven't gone looking 
> for documentation on the history command, perhaps this behavior is reasonably 
> documented.

!

man bash

Cheers,
David.

Re: [Resolved] Re: Bug or Feature in mate-search-tool ?

[Curt]

On 2018-01-14, Richard Owlett  wrote:
> On 01/14/2018 10:23 AM, Richard Owlett wrote:
>> If a file is in a folder below a hidden folder, it will *NOT* be found.
>> This happens even when "Show hidden and backup files" is chosen.
>> It does not matter if logged-in as superuser.
>> I proved it by copying a folder under a hidden folder to a normal
>> folder. Target file was found.
>>
>> I installed from a purchased DVD of Debian 9.1.0 .
>
> I just did a Netinstall of 9.3 on another machine.
> The problem is no longer there ;)
>
>

They must have called in the RIT (rapid intervention team).

-- 
Though I speak with the tongues of men and of angels, and have not charity, I
am become as sounding brass, or a tinkling cymbal.  And though I have the gift
of prophecy, and understand all mysteries, and all knowledge; and though I have
all faith, so that I could remove mountains, and have not charity, I am nothing.

Re: history issue - bug?

[David Wright]

On Sun 14 Jan 2018 at 17:46:51 (+0100), Hans wrote:
> Am Sonntag, 14. Januar 2018, 08:41:21 CET schrieb David Wright:
> Hi David,
> 
> thanks for enlightening me. I always though, that "history -c" would clear 
> all 
> the history and its files as the help file says:
> 
> -cclear the history list by deleting all of the entries
> 
> So IMO this should delete all related history files, even bash_history. 

Sorry, but that wouldn't be how the English in that statement would
normally be understood.

> And as far as I remember, this did it do in former times. 

Not in bash 2.

> In my eyes this is a security hole, as someone, who gaines root somehow (what 
> already is bad eneough) might get more informations of commands, root did in 
> the past. 

If this concerns you, truncate ~/.bash_history and chmod a=r.

> As I said, history -c should delete ALL traces of history, just as the help 
> files tells, shouldn't it?

No. you lose functionality.

> As you confirmed, it does not and you also 
> confirmed, that this is normal behaviour. 

Yes, and it follows the documentation.

> In this case, I recommend this as a failure-by-design.

> Again, thanks for your clearence, I will file a bug report.

I would prefer you didn't.

> > On Sun 14 Jan 2018 at 14:07:01 (+0100), Hans wrote:
> > > Hi folks,
> > > 
> > > try this:
> > > 
> > > 1. login as normal user
> > > 
> > > 2. become root with "su -"
> > 
> > … which reads ~/.bash_history into what I call the command recall buffer.
> > 
> > > 3. delete history with "history -c"
> > 
> > … which deletes all the entries in the recall buffer, those just read
> >   in and those commands typed since logging in.
> > 
> > > 4. Check history, history is gone
> > 
> > Presumably you mean you just tried to recall a command and failed.
> > Make that command "ls -l ~/.bash_history" and you'll see the file
> > is still there.
> > 
> > > 5. logout from root by "CTL + D" or "exit"
> > > 
> > > 6. relogin as root with "su -"
> > 
> > … which reads ~/.bash_history.
> > 
> > > 7. Check history, voila, it appears again.
> > 
> > … as expected.
> > 
> > > What is wrong?
> > 
> > Distinguish between history list and history file.
> > 
> > To eliminate your history, you need to remove/empty the file and
> > also clear the list just before you logout.

Cheers,
David.

[Resolved] Re: Bug or Feature in mate-search-tool ?

[Richard Owlett]

On 01/14/2018 10:23 AM, Richard Owlett wrote:

If a file is in a folder below a hidden folder, it will *NOT* be found.
This happens even when "Show hidden and backup files" is chosen.
It does not matter if logged-in as superuser.
I proved it by copying a folder under a hidden folder to a normal
folder. Target file was found.

I installed from a purchased DVD of Debian 9.1.0 .


I just did a Netinstall of 9.3 on another machine.
The problem is no longer there ;)

Re: history issue - bug?

[Brian]

On Sun 14 Jan 2018 at 18:25:09 +0100, Hans wrote:

> Am Sonntag, 14. Januar 2018, 12:14:47 CET schrieb bw:
> > On Sun, 14 Jan 2018, Hans wrote:
> > > Am Sonntag, 14. Januar 2018, 08:41:21 CET schrieb David Wright:
> > > Hi David,
> > > 
> > > thanks for enlightening me. I always though, that "history -c" would clear
> > > all the history and its files as the help file says:
> > > 
> > > -cclear the history list by deleting all of the entries
> > > 
> > > So IMO this should delete all related history files, even bash_history.
> > 
> > Shouldn't it do what it says it will do?
> > 
> > It says "clear... the list" it does not say delete files.  I can't answer
> > the question about how long it has been this way, but I'm sure it is
> > documented, so maybe look that up before fiing a bug about it?
> 
> It looks like we understand different. 

Indeed. It's not unusual for this to happen, even amongst native
speakers of English (or any other language, I presumme).
 
> -cclear the history list by deleting all of the entries
> 
> It says: .ALL of the entries

Correct.
 
> IMHO all means ALL, regardless in which file or if in memory.
> Otherwise this command would not make any sense, too.

You are the one who is imposing "...in which file or if in memory".
All does mean ALL (you're not a politician, are you :) ). The commands
used in a session are saved in memory in a *list* and written to a
*file* when you log out.
 
> Of course, one can see it in another way than me...

Search on "history list" in the bash manual.

-- 
Brian.


> Cheers
> 
> Hans
> 
> 
> 

Re: history issue - bug?

[rhkramer]

On Sunday, January 14, 2018 12:14:47 PM bw wrote:
> On Sun, 14 Jan 2018, Hans wrote:
> > Am Sonntag, 14. Januar 2018, 08:41:21 CET schrieb David Wright:
> > Hi David,
> > 
> > thanks for enlightening me. I always though, that "history -c" would
> > clear all the history and its files as the help file says:
> > 
> > -cclear the history list by deleting all of the entries
> > 
> > So IMO this should delete all related history files, even bash_history.
> 
> Shouldn't it do what it says it will do?
> 
> It says "clear... the list" it does not say delete files.  I can't answer
> the question about how long it has been this way, but I'm sure it is
> documented, so maybe look that up before fiing a bug about it?

I don't know if I want to comment or not.  To me, it takes a fairly savvy user 
to recognize that list and file are not synonymous--for many casual users 
(including me, and I consider myself generally as something more than just a 
casual user), that documentation is not sufficient.

At the risk of overkill, I would have written the documentation with a note to 
clarify exactly what I said above--something like (with a not full 
understanding of where / how the list is stored):

"clear ... the list, but please note that there is both a list with the 
command history, and a file.  History -c clears that list, but not the file, 
and 
when events occuur (like a new login), the history list is restored from the 
history file.  The history file is in , and if you want to eradicate 
most traces of the history file, you must also delete that file, and, 
potentially, if that critical, any backups.

To me, if it will not be considered a bug in the implementation of the history 
command, it is a bug in the documentation.  (Of course, I haven't gone looking 
for documentation on the history command, perhaps this behavior is reasonably 
documented.  I would think it should be covered under the -h option, or maybe 
if several options need to discuss the existence of the history file, at least 
a note under the -h option something like: : see  for discussion of 
the history file and the distinction between it and the history list.

Re: history issue - bug?

[Hans]

Am Sonntag, 14. Januar 2018, 12:14:47 CET schrieb bw:
> On Sun, 14 Jan 2018, Hans wrote:
> > Am Sonntag, 14. Januar 2018, 08:41:21 CET schrieb David Wright:
> > Hi David,
> > 
> > thanks for enlightening me. I always though, that "history -c" would clear
> > all the history and its files as the help file says:
> > 
> > -cclear the history list by deleting all of the entries
> > 
> > So IMO this should delete all related history files, even bash_history.
> 
> Shouldn't it do what it says it will do?
> 
> It says "clear... the list" it does not say delete files.  I can't answer
> the question about how long it has been this way, but I'm sure it is
> documented, so maybe look that up before fiing a bug about it?

It looks like we understand different. 

-cclear the history list by deleting all of the entries

It says: .ALL of the entries

IMHO all means ALL, regardless in which file or if in memory.
Otherwise this command would not make any sense, too.

Of course, one can see it in another way than me...

Cheers

Hans