Re: [Nmh-workers] Mailing list archives busticated

[Earl Hood]

On Sun, Apr 20, 2014 at 9:35 PM, Ken Hornstein wrote:

> I don't look at the headers of every message I get, but I did check my
> mailbox for examples when I was writing the RFC 2231 parser.  I have
> never seen an extended MIME parameter on a Content-Type header "in the
> wild", but I do see them all of the time on Content-Disposition headers
> (when the filenames get really long).

Wonder what MUAs are nice to do that?

>From what I get, at least from my coworkers that mostly use Outlook,
parts are not used, even for very long filenames.

At a message I just looked at, Outlook appears to wrap the value itself
vs using parts.  For example:

  Content-Disposition: attachment; filename=
  "This is a really long filename that outlook just appears to
   wrap instead of breaking up into parts.txt"

Of course, I hate Outlook with the passion of a thousand suns.  It does
seems that the popular MUAs do not fully leverage all of MIME and are
not good about following open standards.

In my somewhat-organized test data I have been using, I did not have a
sample that used attribute parts.  Well, I have one now ;)

--ewh

P.S. MHonArc does check the content-disposition header, but for security
reasons, mhonarc ignores it by default.  A person can enable honoring
the filename, but they better understand the risks when doing so.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Mailing list archives busticated

[Ken Hornstein]

>Nice of you to take the blame, but the real blame is the brain dead
>parsing code in mhonarc, which appears I never really tested.  Why the
>problem was never discovered before is beyond me (likely since attribute
>parts are rarely used in the wild).

I don't look at the headers of every message I get, but I did check my
mailbox for examples when I was writing the RFC 2231 parser.  I have
never seen an extended MIME parameter on a Content-Type header "in the
wild", but I do see them all of the time on Content-Disposition headers
(when the filenames get really long).  So if you're not parsing the
Content-Disposition header, it doesn't surprise me that you'd never
encounter them; when you think about it, there really aren't that many
MIME parameters out there in common use.

>I've updated the archiving software on mhonarc.org that contains a fix
>to the problem, so the nmh-workers (HTML) archive there should be
>updating again: .

Thanks!

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Mailing list archives busticated

[Earl Hood]

On Sun, Apr 20, 2014 at 8:29 PM, Ken Hornstein wrote:
> I just wanted everyone to know that right now the mailing list archives
> are broken, and it's my fault.

Nice of you to take the blame, but the real blame is the brain dead
parsing code in mhonarc, which appears I never really tested.  Why the
problem was never discovered before is beyond me (likely since attribute
parts are rarely used in the wild).


> I've already been in communication with Earl Hood (the author of
> MHonArc) who confirmed the issue, and he's developing a fix right now.
> I don't know when that fix will make it to the mailing list archives on
> savannah, though.  The archives on mhonarc.org should be fixed soon,
> and you can still access the raw mbox file from the archives on
> savannah.

I've updated the archiving software on mhonarc.org that contains a fix
to the problem, so the nmh-workers (HTML) archive there should be
updating again: .

--ewh

P.S.  It appears the IETF archive on mhonarc.org was also affected since
I saw the same error in the log for it as for nmh-workers.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] Mailing list archives busticated

[Ken Hornstein]

I just wanted everyone to know that right now the mailing list archives
are broken, and it's my fault.

Specifically, it turns out that MHonArc (the software which builds the
web pages from the raw messages) has a bug parsing some MIME parameters
that are encoded with RFC 2231 rules.  And it turns out that if send out
a message/external-body pointer with a long-enough URL, a newer version
of nmh will use those encoding rules ... and that's what I did for the
RC2 version of nmh.

I've already been in communication with Earl Hood (the author of
MHonArc) who confirmed the issue, and he's developing a fix right now.
I don't know when that fix will make it to the mailing list archives on
savannah, though.  The archives on mhonarc.org should be fixed soon,
and you can still access the raw mbox file from the archives on
savannah.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[Ken Hornstein]

>Hyphens go in the middle of hyphenated words, and basically no place
>else (and when you're typing *roff, should almost never be typed, allow
>*roff to insert hyphens when required - other than words for which the spelling
>demands a hyphen).   \- (minus) basically belongs to mathematics, and similar.

Thanks for the explanation!  I appreciate it.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[Robert Elz]

Date:Sun, 20 Apr 2014 16:34:25 -0400
From:Ken Hornstein 
Message-ID:  <201404202034.s3kkyppc003...@hedwig.cmf.nrl.navy.mil>

  | So exactly when should one use '-', and when should one use \-?

Hyphens go in the middle of hyphenated words, and basically no place
else (and when you're typing *roff, should almost never be typed, allow
*roff to insert hyphens when required - other than words for which the spelling
demands a hyphen).   \- (minus) basically belongs to mathematics, and similar.

Everywhere else you want one of either n or m dashes, \(en or \(em, depending
upon how wide you want it to be.   When producing ascii they all make -
of course, but for better output formats they're all distinct (\- (minus)
is a bit odd, as it is positioned at half digit height, the others at half
n height, which is a bit lower - but that's one reason you really don't
want to mis-use minus as a hyphen.

  | The convention seems to be \- is used as the prefix to switches, for
  | example, but why?

In commands like "ls -l" (or refile -retainsequences) the switch indicator
(the -) was selected as the ascii character, then had to be mapped
to one of the dash types when typeset ... hyphens are too short, and look
ugly, n & m dashes are a bit too wide (m dash much too wide), minus is
what was left...   It also fits kind of neatly with the analogy to
negative numbers, which is normally the only place (unix command switches 
excepted) that you ever see a "word" starting with a dash type glyph, (that
is, -2 is natural, -foo (if it isn't a switch) is not).  Dashes otherwise 
normally appear surrounded by spaces (or each other) or with word
characters on both sides.

kre


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[Ken Hornstein]

>.PP
>As message sequences are folder-specific,
>moving the message from the source folder removes it from all its
>sequences in that folder.
>.B \-retainsequences
>adds it to those same sequences in the destination folder,
>creating any that don't exist.
>This adding does not apply for the \*(lqcur\*(rq sequence.

Thanks Ralph; changes applied!

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[Ken Hornstein]

>I see two solutions: call clsfolds() before the call to folder_delmsgs()/
>context_save(), or call context_save() again after the call to clsfolds().
>I do not know if there are any side effects for the first solution (I think
>not); for the latter solution in the worst case that would involve
>two writes of the context file for private sequences (context_save()
>will not write the context file if nothing has changed).

What I decided to do was to move the call to clsfolds(); that seemed
like the safest solution.  That solves the problem; the change will be
in the next 1.6 release candidate.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Patch: backup prefix assumption corrections

[Ken Hornstein]

>I made those changes, but then ran into a problem. If you set
>--with-backup-prefix to soemthing in a pound sign e.g; .# or #
>...things blow up Makefile.am does not seem to have any facility
>for escaping interpolated values, and apparently pounds signs
>aren't portable in Makefile variable values anyhow.
>
>  http://lists.gnu.org/archive/html/automake/2011-08/msg00023.html

Ah, crud.  I didn't know that.  I guess that won't work, will it?
Let me think about this more; we'll have to come up with something better.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[Ken Hornstein]

>BTW, the man pages are a bit \- happy, using it where a normal hyphen is
>needed between words, e.g.

So exactly when should one use '-', and when should one use \-?  I know,
one is a hypen, and one is an minus, but that's not exactly helpful.
The convention seems to be \- is used as the prefix to switches, for
example, but why?

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[Ken Hornstein]

>The special case that the destination folder is the same as the source folder,
>might cause a problem?

I ... do not believe it will result in a functional change.  I think that
problem exists already.  Also ... if you did that, exactly what are
you trying to do, anyway?

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[norm]

Ken Hornstein  writes:
>>> I don't have the time to spend debugging it right now.
>>
>>Would you put it on your todo list so that, if you ever get time and
>>inclination, you will fix it.
>
>A code inspection suggested to me that it should have worked; everything
>was happening where it was supposed to.  It was bugging me, so I took a
>closer look at it.
>
>Normally a call to seq_save() saves the sequences.  For public sequences,
>this causes the sequence file to be written out.  For private sequences,
>it causes the sequences to be added to the context structure (and the
>context structure is marked as being modified).
>
>In the private sequence case, you need to make sure that context_save() is
>called after seq_save().  Normally this is done everywhere ... except in
>the case of refile -retainseq.  seq_save() is called on the source folder
>before context_save(), but for the destination folders seq_save is called
>by the function clsfolds().  And clsfolds() is called _after_ the call
>to context_save (or folder_delmsgs(), which also calls context_save()).
>
>I see two solutions: call clsfolds() before the call to folder_delmsgs()/
>context_save(), or call context_save() again after the call to clsfolds().
>I do not know if there are any side effects for the first solution (I think
>not); for the latter solution in the worst case that would involve
>two writes of the context file for private sequences (context_save()
>will not write the context file if nothing has changed).
>
>Thoughts?  Seems like a legitimate bug fix that should be able to make
>it into 1.6.

The special case that the destination folder is the same as the source folder,
might cause a problem?


Norman Shapiro

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[Ken Hornstein]

>> I don't have the time to spend debugging it right now.
>
>Would you put it on your todo list so that, if you ever get time and
>inclination, you will fix it.

A code inspection suggested to me that it should have worked; everything
was happening where it was supposed to.  It was bugging me, so I took a
closer look at it.

Normally a call to seq_save() saves the sequences.  For public sequences,
this causes the sequence file to be written out.  For private sequences,
it causes the sequences to be added to the context structure (and the
context structure is marked as being modified).

In the private sequence case, you need to make sure that context_save() is
called after seq_save().  Normally this is done everywhere ... except in
the case of refile -retainseq.  seq_save() is called on the source folder
before context_save(), but for the destination folders seq_save is called
by the function clsfolds().  And clsfolds() is called _after_ the call
to context_save (or folder_delmsgs(), which also calls context_save()).

I see two solutions: call clsfolds() before the call to folder_delmsgs()/
context_save(), or call context_save() again after the call to clsfolds().
I do not know if there are any side effects for the first solution (I think
not); for the latter solution in the worst case that would involve
two writes of the context file for private sequences (context_save()
will not write the context file if nothing has changed).

Thoughts?  Seems like a legitimate bug fix that should be able to make
it into 1.6.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[Ralph Corderoy]

Hi David,

> > The nmh-1.6-RC1 refile man page says:
> >
> > The -retainsequences switch causes the memberships in sequences, except
> > "cur", of the refiled messages to be carried over to each destination
> > folder.
> 
> I wasn't fond of that sentence when I wrote it.  And I'm
> still not.  But I can't think of anything better.
> Contributions are welcome.

.PP
As message sequences are folder-specific,
moving the message from the source folder removes it from all its
sequences in that folder.
.B \-retainsequences
adds it to those same sequences in the destination folder,
creating any that don't exist.
This adding does not apply for the \*(lqcur\*(rq sequence.

BTW, the man pages are a bit \- happy, using it where a normal hyphen is
needed between words, e.g.

fixed semantics on a per\-folder basis
Message sequences are folder\-specific

`per-folder' is correct.

Cheers, Ralph.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Any more changes for RC2?

[David Levine]

Paul F. wrote:

> david wrote:
>  > What now? alist
>  > bar.txt
>  > baz.txt
>  > foo.txt
> 
> interesting that it dropped your /tmp prefix.  i've reproduced that --
> i'd say it's a bug.  if anything, alist should be reporting absolute
> paths, to ensure no discrepancy between the pathname relative to whatnow's
> cwd versus the cwd of the editor when the user may have created their
> Attach header.  (this has bitten me in the past, when using mhbuild
> directives.)

That's done by annolist(), which is also used by anno(1).  You
were hoping to find some code with no interdependencies? :-)

Also, I like it the way it is.  If you want to see the full path,
attach -v will show it.

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Any more changes for RC2?

[Paul Fox]

i wrote:
 > david wrote:
 >  > What now? alist
 >  > bar.txt
 >  > baz.txt
 >  > foo.txt
 > 
 > interesting that it dropped your /tmp prefix.  i've reproduced that --
 > i'd say it's a bug.  if anything, alist should be reporting absolute

i see now that "alist -l" shows full paths.  (i actually expected it to
give the output of ls -l.)  i still think the lack of full paths from alist
is questionable.

paul
--
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 45.7 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Any more changes for RC2?

[Ken Hornstein]

> > What now? alist
> > bar.txt
> > baz.txt
> > foo.txt
>
>interesting that it dropped your /tmp prefix.  i've reproduced that --
>i'd say it's a bug.  if anything, alist should be reporting absolute
>paths, to ensure no discrepancy between the pathname relative to whatnow's
>cwd versus the cwd of the editor when the user may have created their
>Attach header.  (this has bitten me in the past, when using mhbuild
>directives.)

Hm, it looks like if you give the -l option to alist, it will report full
pathnames.  I guess it's always behaved that way.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Any more changes for RC2?

[Paul Fox]

david wrote:
 > > >it's now the primary UI for attachments.  why not make it a rich UI?
 > 
 > > Those aren't insurmountable, but somehow mhbuild feels like the wrong
 > > place to be processing shell globbing.  We have enough higher level tools
 > > to do that (you can do it from the attach command,
 > 
 > Right:
 > 
 > What now? ls *.txt
 > bar.txt  baz.txt  foo.txt
 > 
 > What now? at *.txt
 > 
 > What now? li
 > To: 
 > Attach: /tmp/bar.txt
 > Attach: /tmp/baz.txt
 > Attach: /tmp/foo.txt
 > 
 > 
 > Paul, is there really a need to support shell globbing of Attach:
 > pseudoheaders?

no, i suppose not.  i had forgotten that whatnow went through the shell.

 > 
 > And let me note that the whatnow command is passed through the user's
 > shell.  I rely on bash-isms, e.g., "at foo{4..7}.pdf", all the time.
 > 
 > > >perhaps what's needed instead is a confirmation step at whatnow, to
 > > >confirm that what's been attached is what was intended.
 > 
 > There already is an al(ist):
 > 
 > What now? alist
 > bar.txt
 > baz.txt
 > foo.txt

interesting that it dropped your /tmp prefix.  i've reproduced that --
i'd say it's a bug.  if anything, alist should be reporting absolute
paths, to ensure no discrepancy between the pathname relative to whatnow's
cwd versus the cwd of the editor when the user may have created their
Attach header.  (this has bitten me in the past, when using mhbuild
directives.)

 > 
 > And you can also view (and edit) the message after running mhbuild
 > ("mime" at the whatnow prompt) on it.

okay.  i think i'm convinced.  thanks.

paul
--
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 46.9 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[Ken Hornstein]

>I'd still like to understand the value of private sequences.

I asked this question before, and I got three basic answers:

- They're useful if you share a folder with other people (perhaps people
  still do that, but what I'm seeing more often is for nmh users, Every
  Person is an Island).  I'd rather have this controllable on a per-folder
  basis myself.

- They're useful if you have a folder on read-only media.  That seems
  incredibly rare to me, but whatever.  I will note that the sequence
  code will automatically make sequences private if it detects the
  folder in question is read-only; you don't need to do it globally.

- Some people prefer all of their sequences in one file.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[Ralph Corderoy]

Hi David,

> I'd still like to understand the value of private sequences.

For shared folders?

Cheers, Ralph.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[David Levine]

Norm wrote:

> The sentence won't get you a Nobel prize in literature

:-)

> Would you put it on your todo list so that, if you ever get
> time and inclination, you will fix it.

Sure, but there's plenty ahead of it.  One of us may trip over
the answer while poking around.

I'd still like to understand the value of private sequences.

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[norm]

David Levine  writes:

>I wasn't fond of that sentence when I wrote it.

The sentence won't get you a Nobel prize in literature, but I understood it
fine, and others will too. I was confused by -retainsequencesnot not working
for private sequences, and so assumed that I didn't understand the sentence.

> I don't have the time to spend debugging it right now.

Would you put it on your todo list so that, if you ever get time and
inclination, you will fix it.

Thank you,

Norman Shapiro

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] refile's -retainsequences switch

[David Levine]

> The nmh-1.6-RC1 refile man page says:
>
> The -retainsequences switch causes the memberships in sequences, except
> "cur", of the refiled messages to be carried over to each destination
> folder.
>
>I am truly sorry, to be so dense, but I can't decipher that
>sentence. In this context, I don't know what is meant by "membership"
>(I think as the members of sequences as messages) or by "carried
>over". Would some nice person help me.

I wasn't fond of that sentence when I wrote it.  And I'm
still not.  But I can't think of anything better.
Contributions are welcome.

> >So, I guess our dialog constitutes a bug report.
> 
> Well, the person who wrote that code should speak up; looking at it
> again, there's no reason it _shouldn't_ work on private sequences
> that I can see (I misread the use of the is_seq_private() macro).  We
> might just be missing a context_save() somewhere.

That would be me.  I don't have the time to spend debugging
it right now.  If no one else does, I'd be glad to add a
note to the man page that the feature is not supported with
private sequences.

We have another case where private sequences diverge from
public sequences, see the Sequence File Locking note at the
end of the mh-sequence(5) man page.

Which brings me to another point:  do private sequences
serve any real need?  This is as close as I can get to
something useful:

you can actually have more than one set of private
sequences by using different context files.

Though I can do the same thing with public sequences, using
the mh-sequences profile entry.

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Any more changes for RC2?

[David Levine]

> >it's now the primary UI for attachments.  why not make it a rich UI?

> Those aren't insurmountable, but somehow mhbuild feels like the wrong
> place to be processing shell globbing.  We have enough higher level tools
> to do that (you can do it from the attach command,

Right:

What now? ls *.txt
bar.txt  baz.txt  foo.txt

What now? at *.txt

What now? li
To: 
Attach: /tmp/bar.txt
Attach: /tmp/baz.txt
Attach: /tmp/foo.txt


Paul, is there really a need to support shell globbing of Attach:
pseudoheaders?

And let me note that the whatnow command is passed through the user's
shell.  I rely on bash-isms, e.g., "at foo{4..7}.pdf", all the time.

> >perhaps what's needed instead is a confirmation step at whatnow, to
> >confirm that what's been attached is what was intended.

There already is an al(ist):

What now? alist
bar.txt
baz.txt
foo.txt

And you can also view (and edit) the message after running mhbuild
("mime" at the whatnow prompt) on it.

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers