Re: Replies bypassing "accept" file
In article <v0313030db836032b2a4e@[192.168.123.10]>, Charlie Summers <charlie@lofcom.com> writes:
At 12:11 AM -0500 12/7/01, Remco Rijnders is rumored to have typed:
This is counter intuitive though. I know what it says and all that, but it easily leads you to assume that the "uncomment this line" part refers to the line just before it.
It says pretty clearly to uncomment THIS line, not the line before it.
C programs often use the same text, but it means exactly the opposite thing: /* HAVE_BLURFL: uncomment this line if your system has the blurfl() system call. */ /* #define HAVE_BLURFL */ The idiosyncratic syntax of procmail scripts makes the "uncomment this line" text more ambiguous than it might otherwise be. Sorry, Charlie. It sucks.
At 2:34 PM -0500 12/22/01, Tim Pierce is rumored to have typed:
C programs often use the same text, but it means exactly the opposite thing:
/* HAVE_BLURFL: uncomment this line if your system has the blurfl() system call. */ /* #define HAVE_BLURFL */
(*sigh*) I hate being placed in the position of sounding like I'm defending something I agree is flawed, but this isn't the same thing at all and you know it. Mr. Rijnders said:
but it easily leads you to assume that the "uncomment this line" part refers to the line just before it. ^^^^^^
...which is _obviously_ different that using "this" to note a _following_ line. I'm not arguing the single/double hash thing isn't goofy, but the comments make sense considering they are on the _same_ line, something like: //#define HAVE_BLURFL //uncomment this line blablabla But then, you're going to argue with me if I suggest the sky is blue, so I'll let you have the last word on the list, and reinstate that list-level filter. Charlie
participants (2)
-
Charlie Summers -
Tim Pierce