[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
The following reply was made to PR bin/54764; it has been noted by GNATS.
Cc: christos%netbsd.org@localhost, steffen%sdaoden.eu@localhost
Subject: Re: bin/54764
Date: Mon, 16 Dec 2019 13:52:24 +0000 (GMT)
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.
Main Index |
Thread Index |