Re: bin/54764

[elo%foobox.net@localhost]

The following reply was made to PR bin/54764; it has been noted by GNATS.

From: elo%foobox.net@localhost
To: gnats-bugs%NetBSD.org@localhost
Cc: christos%netbsd.org@localhost, steffen%sdaoden.eu@localhost
Subject: Re: bin/54764
Date: Mon, 16 Dec 2019 13:52:24 +0000 (GMT)

 Hello, Steffen.
 
 Thank you for taking the time to look at the patch I submitted.
 
 > From: Steffen Nurpmeso <steffen%sdaoden.eu@localhost>
 > Date: Sat, 14 Dec 2019 23:40:51 +0100
 >
 > POSIX says "unset or set to null", so assuming that NetBSD Mail
 > does not return NULL when doing "set folder=" (or "set folder")
 > the above needs an additional "&& *mf != '\0')" for POSIX.
 
 I had debated whether to qualify that conditional clause with the
 set-but-empty test, but ultimately decided not to do when I realised
 it would put the file-completion code's treatment of the 'folder'
 variable at odds with that of the mail client proper.
 
 Try this: invoke 'mail' whilst your working directory is other than
 your home directory. With 'folder' unset (and NULL), the 'folders'
 command will return 'No value set for "folder"'. But after any of
 'set folder', 'set folder=' or 'set folder=""' (all three of which
 set 'folder' to an empty string), the 'folders' command will list
 the contents of your _home_ directory.
 
 As per the mail man page, 'If [the folder] name begins with a `/',
 mail considers it to be an absolute pathname; otherwise, the folder
 directory is found relative to your home directory.' That's true
 even if the name is a zero-length string. The client itself is
 making a distinction between NULL and set-but-empty, and I wanted
 the file-completion behaviour to mimic it.
 
 If I've misled myself by this argument, I'd be very grateful to be
 put right. In any case, even if I'm not persuaded to change my mind,
 I'm happy to accept the consensus regarding the patch.
 
 Thanks again for your interest.
 
 elo