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, address@hidden (arlington, ma, where it's 46.9 degrees)