Re: when using `which` send errors to /dev/null

2007-05-26 Thread Vincent Lefevre
On 2007-05-25 12:06:26 -0400, Derek Martin wrote:
> I'm not aware of any Unix-derivative systems where /bin/sh is
> not a Bourne-shell derivative (Bourne Shell, Korn Shell, POSIX shell,
> or Bash).  All of those shells use ':' as the path separator for
> $PATH.  Can you suggest an example?

It seems that bash can accept/use ';' under some conditions. The
autoconf manual (info) says:

`PATH_SEPARATOR'
 If it is not set, `configure' will detect the appropriate path
 separator for the build system and set the `PATH_SEPARATOR' output
 variable accordingly.

 On DJGPP systems, the `PATH_SEPARATOR' environment variable can be
 set to either `:' or `;' to control the path separator `bash' uses
 to set up certain environment variables (such as `PATH').  Since
 this only works inside `bash', you want `configure' to detect the
 regular DOS path separator (`;'), so it can be safely substituted
 in files that may not support `;' as path separator.  So it is
 recommended to either unset this variable or set it to `;'.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


Re: when using `which` send errors to /dev/null

2007-05-26 Thread Cameron Simpson
On 26May2007 12:49, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
| On 2007-05-25 12:06:26 -0400, Derek Martin wrote:
| > I'm not aware of any Unix-derivative systems where /bin/sh is
| > not a Bourne-shell derivative (Bourne Shell, Korn Shell, POSIX shell,
| > or Bash).  All of those shells use ':' as the path separator for
| > $PATH.  Can you suggest an example?
| 
| It seems that bash can accept/use ';' under some conditions. The
| autoconf manual (info) says:
| 
| `PATH_SEPARATOR'
|  If it is not set, `configure' will detect the appropriate path
|  separator for the build system and set the `PATH_SEPARATOR' output
|  variable accordingly.
| 
|  On DJGPP systems, the `PATH_SEPARATOR' environment variable can be
|  set to either `:' or `;' to control the path separator `bash' uses
|  to set up certain environment variables (such as `PATH').  Since
|  this only works inside `bash', you want `configure' to detect the
|  regular DOS path separator (`;'), so it can be safely substituted
|  in files that may not support `;' as path separator.  So it is
|  recommended to either unset this variable or set it to `;'.

Of course, such a system isn't a UNIX system...
-- 
Cameron Simpson <[EMAIL PROTECTED]> DoD#743
http://www.cskk.ezoshosting.com/cs/

I think you're confusing "recognizing" and "understanding" with "caring".
The net is cruel, sometimes, but always fair.
- Rick Gordon <[EMAIL PROTECTED]>


Re: when using `which` send errors to /dev/null

2007-05-26 Thread Vincent Lefevre
On 2007-05-26 21:56:35 +1000, Cameron Simpson wrote:
> Of course, such a system isn't a UNIX system...

Is there any reason why Mutt should not run on non-UNIX systems?

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


Re: [Mutt] #2846: Security vulnerability in APOP authentication

2007-05-26 Thread Mutt
#2846: Security vulnerability in APOP authentication

Comment (by brendan):

 (In [3d1d7f6cf693]) Validate msgid in APOP authentication. Closes #2846

-- 
Ticket URL: 


Re: [Mutt] #2885: Buffer overflows in mutt_gecos_name

2007-05-26 Thread Mutt
#2885: Buffer overflows in mutt_gecos_name

Comment (by Jonathan Smith ):

 (In [736653ce1896]) merge changeset 47d08903b79b: Use signed arithmetic in
 mutt_gecos_name to avoid an overflow. Closes #2885.

-- 
Ticket URL: 


mime, freedesktop.org and mutt

2007-05-26 Thread Brian Salter-Duke
I posted this to mutt-users and Kyle there suggested posting it here.
 
This message may be complete nonsense. I am trying to find my way into
something. I understand that KDE 4 and GNOME > 2.4 use the
freedesktop.org mime databases to determine the mime type. 

Has any thought ever been given to using these databases in mutt in 
place of mime.types when sending mail and in place of mailcap on receipt 
of mail and when using auto_view? 

The possible advantages could be that it is possible to sort out
conflicting mime types by doing some 'magic' on the file itself on the
fly. I come to this because I have just come back to improving and
adding to various ways I put forward for dealing with chemical mime
type: chemical/x-?? in mutt. A very common extension *.pdb for Protein 
Database Files uses chemical/s-pdb but this conflicts with *.pdb using
/application/vnd.palm. We could possibly use the freedesktop mime
databases to sort this and other problems out.

There is a new project on chemical mime that is adding chemical mime 
types and information for parsing the files involved to these freedesktop.org 
mime databases.

I hope I have not made too many mistakes in the above. I am still trying
to get into it.

Is this the linux way of the future for mime? If so, should we not be
getting mutt to know about it, if we want to stay ahead of the pack on
support for mime. Has anyone thought about this? Is it already in mutt?
Is is possible or even desirable?

Brian.

-- 
On two occasions I have been asked [by members of Parliament], "Pray, Mr. 
Babbage, if you put into the machine wrong figures, will the right answers 
come out?". I am not able rightly to comprehend the kind of confusion of 
ideas that could provoke such a question.
   -- Charles Babbage
Brian Salter-Duke (Brian Duke) Email: b_duke(AT)bigpond(DOT)net(DOT)au


Re: when using `which` send errors to /dev/null

2007-05-26 Thread Cameron Simpson
On 26May2007 18:37, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
| On 2007-05-26 21:56:35 +1000, Cameron Simpson wrote:
| > Of course, such a system isn't a UNIX system...
| 
| Is there any reason why Mutt should not run on non-UNIX systems?

I can think of numerous things that might fail: maildir file names,
curses support and ttys, etc. By the time you have all that you are well
into POSIX support land and probably best off with a decent UNIXish
environment. For example Cygwin on Windows. And in such environments,
$PATH uses ":" as a separator as usual.

The point here is that once you start trying to support nonUNIX,
the number of things that suddenly must become tunable becomes very
very large.  Better to let a proper emulation layer (wine on windows,
ape on plan9, etc) do all that and then _not_ try to cope with weird
systems that do bizarre things like semicolon $PATH separators.

But by all means handle UNIX variations.

Cheers,
-- 
Cameron Simpson <[EMAIL PROTECTED]> DoD#743
http://www.cskk.ezoshosting.com/cs/

The abdomen, the chest, and the brain will forever be shut from the intrusion
of the wise and humane surgeon.
  --Sir John Eric Ericksen, British surgeon, appointed Surgeon-
Extraordinary  to Queen Victoria 1873.


Re: when using `which` send errors to /dev/null

2007-05-26 Thread Vincent Lefevre
On 2007-05-27 08:26:53 +1000, Cameron Simpson wrote:
> On 26May2007 18:37, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> | On 2007-05-26 21:56:35 +1000, Cameron Simpson wrote:
> | > Of course, such a system isn't a UNIX system...
> | 
> | Is there any reason why Mutt should not run on non-UNIX systems?
> 
> I can think of numerous things that might fail: maildir file names,

There are other mailbox formats and they may be sufficient.

> curses support and ttys, etc.

curses has been ported on other systems (for instance, the ncurses
library has been ported to OS/2 Warp).

> The point here is that once you start trying to support nonUNIX,
> the number of things that suddenly must become tunable becomes very
> very large.

I'm not sure about that. Anyway, the solution concerning the PATH
separator exists and is well-known. So, why not use it?

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


[Mutt] #2895: mutt should keep a deletion log

2007-05-26 Thread Mutt
#2895: mutt should keep a deletion log

 After spending the past hour or so deleting piles of old email, and then
 watching mutt crash because of some sort of bizarre server-side IMAP bug,
 and losing track of all my deletions, I am somewhat frustrated.

 It would be nice if mutt could keep a deletion log of messages deleted,
 such that, when this case happens, it would be possible to restore the log
 in a new mutt and not have to painstakingly find those deleted messages
 and delete them again.

 Of course it would be nice to fix all the bugs that could cause mutt to
 crash and people to lose work. In this case, it is a difficult-to-debug
 IMAP interaction that I think is really a server-side problem (but of
 course mutt shouldn't crash in any case)...

 So this enhancement request is really a band-aid.

 Still, I think it would be a very helpful band-aid to have.

-- 
Ticket URL: 


Re: [Mutt] #2895: mutt should keep a deletion log

2007-05-26 Thread Mutt
#2895: mutt should keep a deletion log

Comment (by Brendan Cully):

 {{{
 On Sunday, 27 May 2007 at 00:34, Mutt wrote:
 > #2895: mutt should keep a deletion log
 >
 >  After spending the past hour or so deleting piles of old email, and
 then
 >  watching mutt crash because of some sort of bizarre server-side IMAP
 bug,
 >  and losing track of all my deletions, I am somewhat frustrated.
 >
 >  It would be nice if mutt could keep a deletion log of messages deleted,
 >  such that, when this case happens, it would be possible to restore the
 log
 >  in a new mutt and not have to painstakingly find those deleted messages
 >  and delete them again.
 >
 >  Of course it would be nice to fix all the bugs that could cause mutt to
 >  crash and people to lose work. In this case, it is a difficult-to-debug
 >  IMAP interaction that I think is really a server-side problem (but of
 >  course mutt shouldn't crash in any case)...
 >
 >  So this enhancement request is really a band-aid.
 >
 >  Still, I think it would be a very helpful band-aid to have.

 Feel free to sync-mailbox whenever you want to commit your work. As
 long as you don't expunged the messages, they will simply be marked
 deleted on the server.
 }}}

-- 
Ticket URL: 


Re: [Mutt] #2895: mutt should keep a deletion log

2007-05-26 Thread Mutt
#2895: mutt should keep a deletion log

Comment (by John Hawkinson):

 {{{
 Mutt <[EMAIL PROTECTED]> wrote on Sun, 27 May 2007
 at 00:38:28 - in <[EMAIL PROTECTED]>:

 > Comment (by Brendan Cully):

 >  Feel free to sync-mailbox whenever you want to commit your work. As
 >  long as you don't expunged the messages, they will simply be marked
 >  deleted on the server.

 This does not work :(

 It does tend to improve the imap problems somewhat. But if it crashes,
 my deletion state gets lost. (server bug? This is cyrus.)

 (Though also, if I remembered to do that, which I sometimes do,
 then I probably would have remembered that deleting this many messages
 in one go would probably be bad, and have not done it...).

 [EMAIL PROTECTED]
   John Hawkinson
 }}}

-- 
Ticket URL: 


Re: [Mutt] #2895: mutt should keep a deletion log

2007-05-26 Thread Mutt
#2895: mutt should keep a deletion log

Comment (by jhawk):

 Actually, I just got "Fatal: word too long" while running sync-mailbox ($
 n). mutt (1.5.12) didn't crash, but, well, deletion state lost. These
 deletions much less painfully earned, though.

-- 
Ticket URL: 


[Announce] mutt-1.4.2.3 is out

2007-05-26 Thread Brendan Cully
Hi,

I've just released mutt-1.4.2.3. It's 1.4.2.2 plus backported fixes
for CVE-2007-2683 (gecos overflow) and CVE-2007-1558 (APOP MD5
collision attack).


pgp9JJ1uFGy1Z.pgp
Description: PGP signature