From rfg@imrss.org Tue Jun  1 23:52:50 1999
Return-Path: <rfg@imrss.org>
Received: from imrss.org (unknown [199.0.22.2])
	by hub.freebsd.org (Postfix) with ESMTP id 85D001501E
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  1 Jun 1999 23:52:49 -0700 (PDT)
	(envelope-from rfg@imrss.org)
Received: (from rfg@localhost)
	by imrss.org (8.9.3/8.9.3) id CAA17816;
	Wed, 2 Jun 1999 02:52:48 -0400 (EDT)
Message-Id: <199906020652.CAA17816@imrss.org>
Date: Wed, 2 Jun 1999 02:52:48 -0400 (EDT)
From: "Ronald F. Guilmette" <rfg@imrss.org>
Reply-To: rfg@monkeys.com (Ronald F. Guilmette)
To: FreeBSD-gnats-submit@freebsd.org
Subject: vacation(1) documentation and error logging both suck
X-Send-Pr-Version: 3.2

>Number:         11987
>Category:       bin
>Synopsis:       vacation(1) documentation and error logging both suck
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    sheldonh
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun  2 00:00:02 PDT 1999
>Closed-Date:    Thu Jun 17 07:50:29 PDT 1999
>Last-Modified:  Thu Jun 17 12:10:02 PDT 1999
>Originator:     Ronald F. Guilmette
>Release:        FreeBSD 2.2.8-RELEASE i386
>Organization:
Internet Mail Relay Services Survey
>Environment:

	Normal

>Description:

	The man page for vacation(1) doesn't say a damn thing about possible
	non-zero exits codes *or* about the fact that vacation(1) uses
	syslog (or even what specific facility it uses) to log errors.

	This sucks because if you have some problem (e.g. screwing up your
	command line arguments) all you get is a mysterious non-zero exit
	code, which really means that the people who sent you mail get back
	some mail bounce containing a totally mysterious "error 1" from
	sendmail.

	The documentation should be fixed to specify things that may result
	in a non-zero exit status *and* also the fact that the program
	uses syslog(3) to log errors (and it should also mention the
	name of the specific facility used).

	Also, is it even a good idea to put errors from this program into
	the system syslog???  I don't think so.  Normal usesr may not have
	access to that.  The errors should instead be written to (for example)
	~/.vacation.errors or something like that, so that an ordinary end
	luser can get to them.

>How-To-Repeat:

	Just use vacation in your .forward file with bad command line args.
	Good luck figuring out what went wrong unless you have access to the
	syslog log files *and* unless you had logging for the "user" facility
	enabled.  (I had to look in the source to figure this *&^%$ stuff out.)

>Fix:
	
	Fix the bleedin' man page and also make errors go to ~/.vacation.errors


>Release-Note:
>Audit-Trail:

From: Tim Vanderhoek <hoek@freebsd.org>
To: "Ronald F. Guilmette" <rfg@monkeys.com>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck
Date: Wed, 2 Jun 1999 11:38:59 -0400

 On Wed, Jun 02, 1999 at 02:52:48AM -0400, Ronald F. Guilmette wrote:
 > 
 > 	syslog log files *and* unless you had logging for the "user" facility
 > 	enabled.  (I had to look in the source to figure this *&^%$ stuff out.)
 
 Umm, having now looked in the source, you are in a pretty good
 position to actually write a patch that at least partially closes your
 problem report...  Submitting a patch as a fix would make this much
 more likely to get dealt with.
 
 > >Fix:
 > 	
 > 	Fix the bleedin' man page and also make errors go to ~/.vacation.errors
 
 [get dealt with ... than this as a fix].
 
 
 -- 
 This is my .signature which gets appended to the end of my messages.
 

From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: Tim Vanderhoek <hoek@freebsd.org>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck 
Date: Wed, 02 Jun 1999 10:19:08 -0700

 In message <19990602113859.B90582@mad>, you wrote:
 
 >On Wed, Jun 02, 1999 at 02:52:48AM -0400, Ronald F. Guilmette wrote:
 >> 
 >> 	syslog log files *and* unless you had logging for the "user" facility
 >> 	enabled.  (I had to look in the source to figure this *&^%$ stuff out.)
 >
 >Umm, having now looked in the source, you are in a pretty good
 >position to actually write a patch that at least partially closes your
 >problem report...  Submitting a patch as a fix would make this much
 >more likely to get dealt with.
 
 I wish that I had time to do that.
 
 Unfortunately, I am already over my head in other public service work.
 
 (I am trying to save the Galaxy from spam.  See http://www.imrss.org/ and
 also http://www.imrss.org/dssl.)
 
 
 -- Ron Guilmette, Roseville, California ---------- E-Scrub Technologies, Inc.
 -- Deadbolt(tm) Personal E-Mail Filter demo: http://www.e-scrub.com/deadbolt/
 -- FREE Web Harvester Protection - http://www.e-scrub.com/wpoison/ - Try it!
 -- FREE DynamicIP Spam Filtering - http://www.imrss.org/dssl/ - TELL YOUR ISP!
 
State-Changed-From-To: open->closed 
State-Changed-By: sheldonh 
State-Changed-When: Thu Jun 10 08:31:41 PDT 1999 
State-Changed-Why:  
If you're going to stand on the sidelines and bitch about the  
documentation, at least make sure you read it. Match cancelled due 
to lack of interest. 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: "Ronald F. Guilmette" <rfg@monkeys.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck 
Date: Thu, 10 Jun 1999 19:13:40 +0200

 On Thu, 10 Jun 1999 08:55:51 MST, "Ronald F. Guilmette" wrote:
 
 > Hey!  I paid my dues already as regards to donating time to free
 > software projects.
 
 Perhaps I misread the tone of your message. Regardless, mine wasn't
 called for. Let me offer you a more civil response:
 
 1) Returning >0 is pretty much a standard UNIXism to the extent that
    a manpage that doesn't mention it can't really be said to "suck".
 
 2) The manpage _does_ mention that erorr messages are logged through the
    syslog(3) interface. The manpage has always mentioned this.
 
 3) It _is_ a good idea to log through syslog. The whole point of
    vacation is that it's often used by people who are _away_ from the
    system. Therefore it's usually best for error messages to go
    somewhere that the administrator will pick them up.
 
 4) Because error messages go somewhere that is visible to the
    administrator, the mysterious "error 1" is easy for her to
    investigate.
 
 Hopefully, this provides you with the academic motivation behind my
 somewhat emotional response.
 
 Ciao,
 Sheldon.
 

From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck 
Date: Thu, 10 Jun 1999 10:23:20 -0700

 In message <70683.929034820@axl.noc.iafrica.com>, you wrote:
 
 >
 >
 >On Thu, 10 Jun 1999 08:55:51 MST, "Ronald F. Guilmette" wrote:
 >
 >> Hey!  I paid my dues already as regards to donating time to free
 >> software projects.
 >
 >Perhaps I misread the tone of your message. Regardless, mine wasn't
 >called for. Let me offer you a more civil response:
 >
 >1) Returning >0 is pretty much a standard UNIXism to the extent that
 >   a manpage that doesn't mention it can't really be said to "suck".
 
 That majority of man pages I have seen _do_ document the possible exit codes
 for programs.
 
 >2) The manpage _does_ mention that erorr messages are logged through the
 >   syslog(3) interface. The manpage has always mentioned this.
 
 Hummm... You're right.
 
 I still don't see where the specific syslog facility used by the program
 is mentioned.  That is an _important_ bit of data.  (The facility used
 for logging is the "user" facility.)
 
 >3) It _is_ a good idea to log through syslog. The whole point of
 >   vacation is that it's often used by people who are _away_ from the
 >   system. Therefore it's usually best for error messages to go
 >   somewhere that the administrator will pick them up.
 
 It is _ok_ to log through syslog, but this particular program is commonly
 used by ordinary end users who may not have access to ther relevant syslog
 files (which may be necessary in order to figure out usage problems), and
 thus, error messages should _also_ be written to someplace where the ordinary
 end user has some hope of seeing them, e.g. ~/.vacation.err or something
 like that.
 
 >4) Because error messages go somewhere that is visible to the
 >   administrator, the mysterious "error 1" is easy for her to
 >   investigate.
 
 Right.  But if the sysadmin is away on a three week vacation in the Bahamas,
 and if the poor end user just has to figure out the problem for himself/herself
 then that could be impossible if (as is customary) the syslog files are tucked
 away in some obscure place and/or set with a mode which makes them unreadable
 to mere mortals.
 
 >Hopefully, this provides you with the academic motivation behind my
 >somewhat emotional response.
 
 Ditto.  I must apologize also for _my_ emotional bug report.
 
 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: "Ronald F. Guilmette" <rfg@monkeys.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck 
Date: Thu, 10 Jun 1999 19:58:15 +0200

 On Thu, 10 Jun 1999 10:23:20 MST, "Ronald F. Guilmette" wrote:
 
 > I still don't see where the specific syslog facility used by the program
 > is mentioned.  That is an _important_ bit of data.  (The facility used
 > for logging is the "user" facility.)
 
 vacation(1):
         Fatal errors, such as calling vacation with incorrect arguments,
         or with non-existent logins, are logged in the system log file,
         using syslog(3).
 
 syslog(3):
         LOG_USER      Messages generated by random user processes.  This
                       is the default facility identifier if none is
                       specified.
 
 > Right.  But if the sysadmin is away on a three week vacation in the
 > Bahamas, and if the poor end user just has to figure out the problem
 > for himself/herself
 
 This is not a problem specific to vacation(1).
 
 I really do think this is a simple case of reading too fast. I know it's
 not easy to admit, and I only feel qualified to say so because I myself
 am so good at it.
 
 Ciao,
 Sheldon.
 

From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck 
Date: Thu, 10 Jun 1999 11:19:38 -0700

 In message <72497.929037495@axl.noc.iafrica.com>, you wrote:
 
 >
 >
 >On Thu, 10 Jun 1999 10:23:20 MST, "Ronald F. Guilmette" wrote:
 >
 >> I still don't see where the specific syslog facility used by the program
 >> is mentioned.  That is an _important_ bit of data.  (The facility used
 >> for logging is the "user" facility.)
 >
 >vacation(1):
 >        Fatal errors, such as calling vacation with incorrect arguments,
 >        or with non-existent logins, are logged in the system log file,
 >        using syslog(3).
 >
 >syslog(3):
 >        LOG_USER      Messages generated by random user processes.  This
 >                      is the default facility identifier if none is
 >                      specified.
 
 That fact that "user" is the default facility for syslog, in general
 DOES NOT tell me that this is the facility that will be used, in fact,
 by this specific program.  (Plenty of programs do syslog logging.  Most
 _do_ select the facility they will use explicitly.)
 
 >> Right.  But if the sysadmin is away on a three week vacation in the
 >> Bahamas, and if the poor end user just has to figure out the problem
 >> for himself/herself
 >
 >This is not a problem specific to vacation(1).
 
 How many other end-user-oriented programs write their error to syslog,
 rather than to stderr??
 
 This is the *only* one that I know of.
 
 Maybe there are a few others, but this is certainly an unusual sort of a
 problem... i.e. an end-user-oriented utility program where the end user
 who uses it may not even be allowed to see the error messages it generates!
 
 >I really do think this is a simple case of reading too fast. I know it's
 >not easy to admit, and I only feel qualified to say so because I myself
 >am so good at it.
 
 In a word, no.  I disagree.  I do not believe that this is merely a case
 of me reading too fast.
 
 As I have noted (above) it requires an unjustified leap of faith to intuit
 from the _combination_ of the vacation(1) man page and the syslog(3) man
 page that in fact vacation(1) uses the "user" syslog facility.  Consider:
 
 	The default way of getting from place to place these days is
 	by car.
 
 	Chipmanzees do occasionally move from place to place.
 
 	Therefore chipmanzees drive cars.
 
 The conclusion does not automatically follow from the premises.
 
 Also, as I have noted, vacation(1) is the _only_ end-user-oriented program
 I know of where the end user may not even be allowed to see the error messages
 produced by the program.  (I think that even procmail, which in some ways
 has a similar sort of function, logs its errors into some file in the
 user's home directory so that the poor user can at least see them.  Hummm...
 yes.  I just looked in my own home directory and there is a nice big file
 called .procmail.log.)
 
 OK.  So analogously, what I have proposed is a ~/.vacation.log file.
 
 This suggestion/request is _not_ prompted merely by an excessively speedy
 perusal of the relevant man pages.  It is prompted by a real and legitimate
 need, i.e. the need of an ordinary end user to be able to see his own error
 messages when he invokes some end-user-oriented program.
 
State-Changed-From-To: closed->open 
State-Changed-By: hoek 
State-Changed-When: Thu Jun 10 13:31:56 PDT 1999 
State-Changed-Why:  
There's probably something we can do about this PR. 


Responsible-Changed-From-To: freebsd-bugs->hoek 
Responsible-Changed-By: hoek 
Responsible-Changed-When: Thu Jun 10 13:31:56 PDT 1999 
Responsible-Changed-Why:  
Well, if I'm going to open it, I'd better take responsibility 
for it...  Anybody who actually wants to do anything 
with this is more than welcome!!  :-) 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: Tim Vanderhoek <vanderh@ecf.utoronto.ca>,
	"Ronald F. Guilmette" <rfg@monkeys.com>,
	freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck 
Date: Fri, 11 Jun 1999 03:25:32 +0200

 On Fri, 11 Jun 1999 01:01:52 +0200, Sheldon Hearn wrote:
 
 > Alternatively, and this is what I think would be best, scrap
 > .vacation.log and write to stderr. It's easy enough to redirect to a
 > file from .forward --
 
 I could have sworn I'd done this before from a .forward file
 (redirecting standard streams) but I don't seem to be able to now. The
 only thing I can come up with that works is
 
 "|/bin/sh -c '/usr/bin/vacation -d bob' 2>/home/bob/.vacation.log"
 
 I'm pretty sure I had something neater going on a year or two ago when I
 had reaosn to worry about logging actions out of .forward . Perhaps this
 is a difference between sendmail and exim?
 
 Regardless, I still think that the debugging option should write to
 stderr and not to a file. Debug vacation while you're at the computer.
 Before you go on vacation, take out the debugging option. Makes sense to
 me.
 
 Essentially, what I'm trying to avoid is one of those icky situations
 that arise where a program's behaviour is so sensitive to its
 environment that its behaviour is no longer intuitive. Its behaviour in
 each case seems reasonable, but when it's unleashed on the world, it
 becomes a pain in the ass.
 
 Here's the patch as it stands if you go along with this logic.
 
 Ciao,
 Sheldon.
 
 Index: vacation.1
 ===================================================================
 RCS file: /home/ncvs/src/usr.bin/vacation/vacation.1,v
 retrieving revision 1.6
 diff -u -d -r1.6 vacation.1
 --- vacation.1	1997/02/22 19:57:38	1.6
 +++ vacation.1	1999/06/11 01:09:33
 @@ -40,11 +40,14 @@
  .Nd return ``I am not here'' indication
  .Sh SYNOPSIS
  .Nm vacation
 +.Op Fl d
  .Fl i
  .Op Fl r Ar interval
  .Nm vacation
 +.Op Fl d
  .Fl l
  .Nm vacation
 +.Op Fl d
  .Op Fl a Ar alias
  .Ar login
  .Sh DESCRIPTION
 @@ -71,6 +74,8 @@
  .Ar alias
  in the same manner as those received for the user's
  login name.
 +.It Fl d
 +Enable debugging mode. See below.
  .It Fl i
  Initialize the vacation database files.  It should be used
  before you modify your
 @@ -160,7 +165,14 @@
  with incorrect arguments, or with non-existent
  .Ar login Ns Ar s ,
  are logged in the system log file, using
 -.Xr syslog 3 .
 +.Xr syslog 3
 +unless debugging mode is enabled with the
 +.Fl d
 +option, in which case they are written to the standard error output.
 +.Sh DIAGNOSTICS
 +The
 +.Nm
 +utility exits 0 on success, and >0 if an error occurs.
  .Sh FILES
  .Bl -tag -width "vacation.dirxxx" -compact
  .It Pa ~/.vacation.db
 Index: vacation.c
 ===================================================================
 RCS file: /home/ncvs/src/usr.bin/vacation/vacation.c,v
 retrieving revision 1.13
 diff -u -d -r1.13 vacation.c
 --- vacation.c	1998/10/13 14:52:32	1.13
 +++ vacation.c	1999/06/11 01:24:00
 @@ -62,6 +62,7 @@
  #include <unistd.h>
  #include <stdio.h>
  #include <ctype.h>
 +#include <stdarg.h>
  #include <stdlib.h>
  #include <string.h>
  #include <paths.h>
 @@ -88,6 +89,7 @@
  DB *db;
  
  char from[MAXLINE];
 +void (*msglog)(int, const char *, ...) = &syslog;
  
  static int	isdelim		__P((int));
  static int	junkmail	__P((void));
 @@ -99,6 +101,7 @@
  static void	setinterval	__P((time_t));
  static void	setreply	__P((void));
  static void	usage		__P((void));
 +static void	slog		__P((int, const char *, ...));
  
  int
  main(argc, argv)
 @@ -110,19 +113,24 @@
  	struct passwd *pw;
  	ALIAS *cur;
  	time_t interval;
 -	int ch, iflag, lflag;
 +	int ch, iflag, lflag, mfail;
  
 -	opterr = iflag = lflag = 0;
 +	opterr = iflag = lflag = mfail = 0;
  	interval = -1;
 -	while ((ch = getopt(argc, argv, "a:Iilr:")) != -1)
 +	while ((ch = getopt(argc, argv, "a:dIilr:")) != -1) {
  		switch((char)ch) {
  		case 'a':			/* alias */
 -			if (!(cur = (ALIAS *)malloc((u_int)sizeof(ALIAS))))
 +			if (!(cur = (ALIAS *)malloc((u_int)sizeof(ALIAS)))) {
 +				mfail++;
  				break;
 +			}
  			cur->name = optarg;
  			cur->next = names;
  			names = cur;
  			break;
 +		case 'd':			/* debug mode */
 +			msglog = &slog;
 +			break;
  		case 'I':			/* backward compatible */
  		case 'i':			/* init the database */
  			iflag = 1;
 @@ -143,6 +151,16 @@
  		default:
  			usage();
  		}
 +	}
 +
 +	/* Only die on the above malloc failure here so that the
 +	 * correct logging medium is used.
 +	 */
 +	if (mfail) {
 +		msglog(LOG_ERR, "vacation: malloc failed\n");
 +		exit(1);
 +	}
 +
  	argc -= optind;
  	argv += optind;
  
 @@ -150,17 +168,17 @@
  		if (!iflag && !lflag)
  			usage();
  		if (!(pw = getpwuid(getuid()))) {
 -			syslog(LOG_ERR,
 +			msglog(LOG_ERR,
  			    "vacation: no such user uid %u.\n", getuid());
  			exit(1);
  		}
  	}
  	else if (!(pw = getpwnam(*argv))) {
 -		syslog(LOG_ERR, "vacation: no such user %s.\n", *argv);
 +		msglog(LOG_ERR, "vacation: no such user %s.\n", *argv);
  		exit(1);
  	}
  	if (chdir(pw->pw_dir)) {
 -		syslog(LOG_NOTICE,
 +		msglog(LOG_NOTICE,
  		    "vacation: no such directory %s.\n", pw->pw_dir);
  		exit(1);
  	}
 @@ -168,7 +186,7 @@
  	db = dbopen(VDB, O_CREAT|O_RDWR | (iflag ? O_TRUNC : 0),
  	    S_IRUSR|S_IWUSR, DB_HASH, NULL);
  	if (!db) {
 -		syslog(LOG_NOTICE, "vacation: %s: %s\n", VDB, strerror(errno));
 +		msglog(LOG_NOTICE, "vacation: %s: %s\n", VDB, strerror(errno));
  		exit(1);
  	}
  
 @@ -182,8 +200,10 @@
  		exit(0);
  	}
  
 -	if (!(cur = malloc((u_int)sizeof(ALIAS))))
 +	if (!(cur = malloc((u_int)sizeof(ALIAS)))) {
 +		msglog(LOG_ERR, "vacation: malloc failed\n");
  		exit(1);
 +	}
  	cur->name = pw->pw_name;
  	cur->next = names;
  	names = cur;
 @@ -263,7 +283,7 @@
  	if (!tome)
  		exit(0);
  	if (!*from) {
 -		syslog(LOG_NOTICE, "vacation: no initial \"From\" line.\n");
 +		msglog(LOG_NOTICE, "vacation: no initial \"From\" line.\n");
  		exit(1);
  	}
  }
 @@ -410,16 +430,16 @@
  
  	mfp = fopen(VMSG, "r");
  	if (mfp == NULL) {
 -		syslog(LOG_NOTICE, "vacation: no ~%s/%s file.\n", myname, VMSG);
 +		msglog(LOG_NOTICE, "vacation: no ~%s/%s file.\n", myname, VMSG);
  		exit(1);
  	}
  	if (pipe(pvect) < 0) {
 -		syslog(LOG_ERR, "vacation: pipe: %s", strerror(errno));
 +		msglog(LOG_ERR, "vacation: pipe: %s", strerror(errno));
  		exit(1);
  	}
  	i = fork();
  	if (i < 0) {
 -		syslog(LOG_ERR, "vacation: fork: %s", strerror(errno));
 +		msglog(LOG_ERR, "vacation: fork: %s", strerror(errno));
  		exit(1);
  	}
  	if (i == 0) {
 @@ -428,7 +448,7 @@
  		close(pvect[1]);
  		close(fileno(mfp));
  		execl(_PATH_SENDMAIL, "sendmail", "-f", myname, "--", from, NULL);
 -		syslog(LOG_ERR, "vacation: can't exec %s: %s",
 +		msglog(LOG_ERR, "vacation: can't exec %s: %s",
  			_PATH_SENDMAIL, strerror(errno));
  		_exit(1);
  	}
 @@ -444,7 +464,7 @@
  static void
  usage()
  {
 -	syslog(LOG_NOTICE, "uid %u: usage: vacation [-i [-rinterval]] [-l] [-a alias] login\n",
 +	msglog(LOG_NOTICE, "uid %u: usage: vacation [-d] [-i [-rinterval]] [-l] [-a alias] login\n",
  	    getuid());
  	exit(1);
  }
 @@ -485,4 +505,19 @@
  	if (c == '_' || c == '-' || c == '.')
  		return(0);
  	return(1);
 +}
 +
 +/*
 + * Append a message to the standard error for the convenience of end-users
 + * debugging without access to the syslog messages.
 + */
 +static void
 +slog(int i, const char *fmt, ...)
 +{
 +	va_list ap;
 +
 +	i = 0;			/* Printing syslog priority not implemented */
 +	va_start(ap, fmt);
 +	vfprintf(stderr, fmt, ap);
 +	va_end(ap);
  }
 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: Tim Vanderhoek <vanderh@ecf.utoronto.ca>
Cc: "Ronald F. Guilmette" <rfg@monkeys.com>,
	freebsd-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck 
Date: Fri, 11 Jun 1999 03:40:47 +0200

 On Thu, 10 Jun 1999 21:29:45 -0400, Tim Vanderhoek wrote:
 
 > Man, you really got gyped.  ;-)
 
 Well, when markm discovers mail for him from "Linus Torvalds" on the
 oh-so-easily-exploited Message Board at USENIX tomorrow, I may get
 really _dead_. :-)
 
 > Who knows.  It really only matters for the cases where From: and
 > Return-Path: are different.  I suppose it's probably correct to take
 > the Return-Path: ....  WTF is strlcpy()?
 
 An OpenBSDism. It's a strncpy that always NULL-terminates dst, even if
 src wasn't NULL-terminated within len, and then returns the size of src,
 not dst. Dumb-ass, if you ask me. This is what I get out of their
 manpage, at any rate.
 
 > (RFC 822: Return-Path: "definitive ... route back to the message's
 >                         originator"
 >           From: "the identity of the person who wished this message to
 >                  be sent."
 
 Oh, okay. But are they talking about "From: " or "From "?
 
 I don't think it matters too much at the end of the day. Flip a coin.
 :-P
 
 Ciao,
 Sheldon.
 

From: Tim Vanderhoek <vanderh@ecf.utoronto.ca>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: "Ronald F. Guilmette" <rfg@monkeys.com>,
	freebsd-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck
Date: Thu, 10 Jun 1999 23:45:57 -0400

 On Thu, Jun 10, 1999 at 09:40:47PM -0400, Sheldon Hearn wrote:
 > 
 > An OpenBSDism. It's a strncpy that always NULL-terminates dst, even if
 > src wasn't NULL-terminated within len, and then returns the size of src,
 > not dst. Dumb-ass, if you ask me. This is what I get out of their
 
 <shrug>  We have reallocf().  I guess strlcpy() is a bit less useful,
 but I'll see if I can work it into some piece of code someday anyways.  ;-)
 
 
 > > (RFC 822: Return-Path: "definitive ... route back to the message's
 > >                         originator"
 > >           From: "the identity of the person who wished this message to
 > >                  be sent."
 > 
 > Oh, okay. But are they talking about "From: " or "From "?
 
 From:, I hope.  :)
 
 I'm going to leave it as is and just a note to the commit log.
 
 
 -- 
 This is my .signature which gets appended to the end of my messages.
 

From: Tim Vanderhoek <vanderh@ecf.utoronto.ca>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: "Ronald F. Guilmette" <rfg@monkeys.com>,
	freebsd-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck
Date: Fri, 11 Jun 1999 00:27:23 -0400

 On Thu, Jun 10, 1999 at 09:25:32PM -0400, Sheldon Hearn wrote:
 > 
 > I'm pretty sure I had something neater going on a year or two ago when I
 > had reaosn to worry about logging actions out of .forward . Perhaps this
 > is a difference between sendmail and exim?
 
 Could be.  And then there's qmail's dotforward, and postfix, and god
 knows what else.  Probably just as well that it doesn't work neatly.
 
 
 > Regardless, I still think that the debugging option should write to
 > stderr and not to a file. Debug vacation while you're at the computer.
 > Before you go on vacation, take out the debugging option. Makes sense to
 > me.
 
 Ok, your call.  I would add an output-to-file option, but I've always
 leaned a little bit too far towards the magic side of things.  :)
 
 
 > Here's the patch as it stands if you go along with this logic.
 
 Okay, I'll commit this, modulo a couple style(9) changes (use
 sysexits(3) (even though no one else does :), proper comment style).
 
 
 > +static void	slog		__P((int, const char *, ...));
 
 That's actually a kinda funny name, if you think about it.  :-)
 
 
 style(9): +     /*
           +      * Only ...
 > +	/* Only die on the above malloc failure here so that the
 > +	 * correct logging medium is used.
 
 > +	if (mfail) {
 > +		msglog(LOG_ERR, "vacation: malloc failed\n");
 > +		exit(1);
 style(9):       exit(EX_TEMPFAIL);
 
 Sendmail also understands that this is a temp failure (if memory is
 permanently so short that vacation never succeeds, a backlog of
 deferred messages is the least of the admin's problems :).
 
 
 -- 
 This is my .signature which gets appended to the end of my messages.
 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: Tim Vanderhoek <vanderh@ecf.utoronto.ca>
Cc: "Ronald F. Guilmette" <rfg@monkeys.com>,
	freebsd-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck 
Date: Fri, 11 Jun 1999 12:30:41 +0200

 On Fri, 11 Jun 1999 00:27:23 -0400, Tim Vanderhoek wrote:
 
 > Ok, your call.  I would add an output-to-file option, but I've always
 > leaned a little bit too far towards the magic side of things.  :)
 
 Well if it's my call, there's no output-to-file option. The more I think
 about it, the more I think it's not useful. :-)
 
 > Okay, I'll commit this, modulo a couple style(9) changes (use
 > sysexits(3) (even though no one else does :), proper comment style).
 
 This is one of the reasons I contribute to FreeBSD -- I get my code
 reviewed by guys with much more experience than me, and learn in the
 process. :-)
 
 > style(9):       exit(EX_TEMPFAIL);
 
 Ah, neat. "All our lines are busy, please try again later."
 
 Thanks for the feedback,
 Sheldon.
 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: Tim Vanderhoek <vanderh@ecf.utoronto.ca>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck
Date: Thu, 17 Jun 1999 16:27:55 +0200

 Hi Tim,
 
 I'm ready to commit the debugging option changes for vacation(1)
 discussed on PR 11987 and want your call on one more thing.
 
 Since calling vacation with neither options nor arguments is illegal
 syntax, I'd like to suggest that doing so _always_ print usage to
 stderr.
 
 Wotcha think?
 
 Ciao,
 Sheldon.
 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: Tim Vanderhoek <vanderh@ecf.utoronto.ca>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck 
Date: Thu, 17 Jun 1999 16:37:35 +0200

 On Thu, 17 Jun 1999 16:27:55 +0200, Sheldon Hearn wrote:
 
 > Since calling vacation with neither options nor arguments is illegal
 > syntax, I'd like to suggest that doing so _always_ print usage to
 > stderr.
 
 I take this suggestion back. It's a bad idea because it makes the
 program's behaviour even more peculiar. Sometimes I do this, sometimes I
 do that and sometimes on a rainy day exactly one fortnight after a
 monkey's wedding in late summer I do something else.
 
 Ciao,
 Sheldon.
 
State-Changed-From-To: open->closed 
State-Changed-By: sheldonh 
State-Changed-When: Thu Jun 17 07:50:29 PDT 1999 
State-Changed-Why:  
Committed. 


Responsible-Changed-From-To: hoek->sheldonh 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Thu Jun 17 07:50:29 PDT 1999 
Responsible-Changed-Why:  
His fix. 

From: Tim Vanderhoek <vanderh@ecf.utoronto.ca>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/11987: vacation(1) documentation and error logging both suck
Date: Thu, 17 Jun 1999 15:03:06 -0400

 On Thu, Jun 17, 1999 at 10:27:55AM -0400, Sheldon Hearn wrote:
 > 
 > Since calling vacation with neither options nor arguments is illegal
 > syntax, I'd like to suggest that doing so _always_ print usage to
 > stderr.
 
 Printing errors to syslog(3) and not stderr when vacation is called
 with the -l or the -i options is also pretty silly.
 
 Just bite the bullet and throw away your illusion of consistent
 performance.  :)
 
 
 -- 
 This is my .signature which gets appended to the end of my messages.
 
>Unformatted:
