LSTOWN-L Archives

LISTSERV List Owners' Forum

LSTOWN-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Eric Thomas <[log in to unmask]>
Fri, 27 Sep 1996 00:47:49 +0200
text/plain (50 lines)
On     Thu,    26     Sep     1996    15:49:14     PDT    Peter     Rauch
<[log in to unmask]> said:
 
>> What's wrong with:
>>
>> Send= access-level [,Semi-Moderated] [,Hold] [,Confirm]
>
>Eric, Are  you asking a  question about  the visual presentation  of the
>keyword syntax, or is this a strictly technical question?
 
Let's just  say my mailbox  was crammed, and  after reading a  half dozen
postings on the subject I just kept asking myself:
 
>> What's wrong with:
>>
>> Send= access-level [,Semi-Moderated] [,Hold] [,Confirm]
 
Which is  exactly the way  it is implemented (although  some combinations
may only make limited sense, but that's not a syntax diagram issue).
 
Then another  half dozen messages  later people  seemed to be  using this
syntax and  I cursed  myself for  not having  finished my  mailbox before
replying :-)
 
>If spaces _are_  allowed, then the syntax model with  spaces in not only
>visually ok, but its technically correct, and I'm delighted.
 
Yes, the spaces are allowed, although  I wouldn't type them, at least not
BEFORE the  comma. Keeping  keywords space free  helps pinpoint  the rule
that a space ends a keyword (unless it's inside a quoted string).
 
>The technical  point about the use  of spaces in the  syntax model arose
>because, if I remember correctly, LISTSERV  used to insist that there be
>a  space following  the "="  in  the keyword  (e.g., "SEND=  ", and  not
>"SEND=" is  correct). Is my recollection  correct? If so, is  this still
>true?
 
No, that has always  been flexible. The problem was with  the fact that a
space ends the keyword, and people putting spaces before or after commas.
This was fixed a long time ago due to failing to educate the users :-)
 
>And, finally,  this whole topic  came up because the  current documented
>definition of  SEND wasn't correct,  apparently (the issue  wasn't about
>the  spaces,  but  about  how  many of  the  parameters  were  legal  to
>simultaneously have in a SEND keyword).
 
Yes, that's what my remark was about :-)
 
  Eric

ATOM RSS1 RSS2