Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Jan 2002 00:10:02 -0800 (PST)
From:      Marc Silver <marcs@draenor.org>
To:        freebsd-doc@freebsd.org
Subject:   Re: docs/31265: crontab(1) doesn't decribe format of allow and deny files.
Message-ID:  <200201020810.g028A2a67875@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/31265; it has been noted by GNATS.

From: Marc Silver <marcs@draenor.org>
To: "Gary W. Swearingen" <swear@blarg.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: docs/31265: crontab(1) doesn't decribe format of allow and deny files.
Date: Wed, 2 Jan 2002 08:04:40 +0000

 On Tue, Jan 01, 2002 at 09:11:40PM -0800, Gary W. Swearingen wrote:
 > The re-write needs work.  I haven't taken the time to re-do the tests
 > upon which my patch was based, but looking at this code from 4.5-Pre
 > leads me to believe nothing's changed relative to the newline issue.
 > 
 >     /usr/src/usr.sbin/cron/lib/misc.c
 > 
 > 	while (fgets(line, MAX_TEMPSTR, file)) {
 > 		if (line[0] != '\0')
 > 			line[strlen(line)-1] = '\0';
 > 		if (0 == strcmp(line, string))
 > 			return TRUE;
 > 
 > Note that it wipes out the last character before the null, which is
 > the newline character except for a line which does not end with a 
 > newline, so that a user name at the end of the file with no trailing
 > newline will be ignored.  It still looks to me like a user name which
 > ends the file will be ignored.  I suspect a testing error.
 
 Firstly, let me say that my c knowledge is not overly impressive, and
 while I understand more or less what's going on there, I'm not about to
 get into a discussion re: it.
 
 I have however re-tested this, and on my machine (4.4-STABLE compiled on
 18 Dec 2001) a username at the end of a file _without_ a newline
 character is still allowed/denied correctly as it's supposed to be.
 There's no testing error here... it works just fine for me.
 
 > As for the rest, if you don't like my terse precision, then please add
 > some more verbiage to yours to indicate that the user names must also
 > not have any characters (such as whitespace) following them on the
 > line.
 
 It's not about liking or disliking your 'terse precision'.  The reason I
 resubmitted this was because my unpatched crontab.1 file seemed
 different to yours, and there had been no action on this PR.  I'm merely
 trying to revive it and hopefully get something done about the problem
 you found.
 
 > I think it's rather silly to say "you must use the correct format".
 
 You're entitled to your opinion.  Do you have a better suggestion?
 
 > I think "username" is not and should not be one word, despite the fact
 > that it often is.
 
 Surely this is a 'religious' debate?  It has nothing to do with whether
 or not the patch is relevant.  I personally do believe that 'username'
 is correct.  A quick search of the man pages in the source tree found
 the word 'username' 139 times... so I'm fairly sure that it's widely
 accepted.
 
 > Saying "Only one username must be added per line." doesn't read well.
 > The sentence which follows that doesn't need a comma; the "or" clause
 > is too short to require it.
 
 Thanks for the grammatical heads-up.  I'll fix that too...
 
 > Saying "Comments may also be inserted into this file." leaves one
 > asking what a legal comment is.  My patch provided that information.
 > A comment is a line which contains something other than a user name
 > followed by a newline.
 
 This has already been brought up, and I'll submit a change later today
 to explain what a comment is.
 
 Quite frankly, I couldn't care if your patch or mine is used at the end
 of the day.  As long as the man page gets corrected.
 
 - Marc
 
 Btw.  Your reply seems somewhat agressive... if I've offended you by
 submitting this, then I apologise.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201020810.g028A2a67875>