At 8:46 AM -0400 7/28/01, Greg Matheson is rumored to have typed:

I agree it is confusing.

No, it isn't; you simply don't understand the convention.

#foreign_submit = yes ##foreign_submit

This means that:

#foreign_submit = yes

...is the pre-set default, and:

##foreign_submit

...will _change_ the default value and do something differently than the "stock" SmartList setup does. Note that ALL THE WAY THROUGH the rc.custom file, this convention is followed for all of the flags...this isn't something arbitrarily done in one instance, but rather runs through the entire rc.custom file to show you the default settings on the flags.

Again, this tells you what the default value of the variable is, without wasting the processing time to re-set it to the same value it already has. Yes, it's copied from rc.init, but there it's _necessary_ to set the variables (that's why it's called rc.INIT); in rc.custom, if you ain't changing it, why re-set it to the value it already contains? I realize with today's processor-wasteful programming styles popularized by the authors of operating systems that require multiple wasted intepreted layers to do anything, it seems foreign, but procmail/SmartList is written to be as fast, small, and processor-friendly as humanly possible, even to the point of not resetting a variable when it isn't necessary. If you have a gighertz machine with gigs of RAM you probably don't care about wasted cycles...fortunately, the maintainers of procmail/SmartList are still more interested in efficiency over sloppiness. If Windows programmers wrote the same way, Windows would run on a 50mHz 386 at almost the speed the current version does on modern machines...imagine how fast it could run on THOSE!

This should really be a FAQ, since it's all _terribly_ helpful; it allows you to easily read how the defaults are set up - no one coming to SmartList seems to grasp how this works, and how really helpful this is. If this doesn't qualify as a FAQ, I don't know what does.

Charlie

At 11:33 AM -0400 7/28/01, Harlan Olson is rumored to have typed:

Charlie, I am really confused now. Check me out below.

Setting by default, not allowing non-subscribers: #foreign_submit = yes ##foreign_submit

My understanding to enable a function it would be removing the "#": foreign_submit = yes ##foreign_submit

Nope; all you're doing by removing the SINGLE comment is re-setting the value to the default already set in rc.init. That is, SmartList ships out-of-the-box allowing _anyone,_ subscriber or not, to post. Removing the single comment simply duplicates the rc.init setting, for no real useful purpose.

To CHANGE the default behavior, you would remove the DOUBLE COMMENTed line, like:

#foreign_submit = yes foreign_submit

Now foreign_submit is unset (destroyed, removed from memory, shown the door), and so only subscribers may post.

The whole idea is to give you an easy way of seeing how SmartList's defaults are set; in this case, if you want everyone to be able to post, you can see that SmartList is already set up that way, and you know you don't need to do anything.

Let's look at another example:

#force_subscribe ##force_subscribe= yes # uncomment to cause people to # be autosubscribed upon first # submission to the list

In this case, we can easily see (by looking at the single commented line) that force_subscribe is unset by default, so posters who are not subscribed will NOT be automagically be subscribed when they make their first (or any) post. If we want to ChANGE that behavior, and auto-subscribe non-subscribed posters, we would uncomment the DOUBLE COMMENT line, setting the content of the variable to "yes":

#force_subscribe force_subscribe= yes

It's all a matter of allowing us to see what the defaults are without having to look in rc.init; by including both values for the flags, and commenting them differently, it supplies a visual cue as to which is "normal" and which is "different."

Charlie

Charlie Summers charlie@lofcom.com wrote:

The whole idea is to give you an easy way of seeing how SmartList's defaults are set; in this case, if you want everyone to be able to post, you can see that SmartList is already set up that way, and you know you don't need to do anything.

That's nice if you know this. Most newbys are getting problems with the comments. Your suggestion for an additional FAQ item regarding the double comments is right but I think the whole configuration should be modified because it's not user friendly.

You may save some cpu cycles if you follow the double/single comment approach but on the other side there are some variables which are set twice even in the default configuration (e. g. X_COMMAND, X_COMMAND_PASSWORD).

I would prefer a solution where there is only one rc.custom as a configuration file (maybe hard linked with rc.init in the list directory). Within rc.custom all variables should be set or empty, i. e.

foreign_submit =

and

unsub_assist = 8

There wouldn't be any more variables with comments in front or without an equal sign and therefore less ambiguity what's set and what's empty. You even won't need more cpu cycles than before ;)

Werner

Charlie Summers charlie@lofcom.com wrote:

Er...are you sure you mean this? If rc.custom is hard-linked to the list directory's rc.init, and the list directory's rc.init is hard-linked to the "main" .etc/.rc.init, changes between lists would be impossible.

You're right it could be an empty file without any link or linked with etc/rc.init and containing only some basic settings (e. g. for the MTA). But you need rc.init because it's hard coded in flist.

And, frankly, I _like_ the linked rc.init - it allows me to make global changes to ALL of my lists easily (which is something I avoided discussing with the folks who were confused, since changing rc.init kinda blows the single/double mnemonic right outta the water) without mucking with each list's seperate rc.custom.

Yes, you would loose the ability to make global changes in rc.init but on the other side you minimize the risks associated with this ability.

I do agree with you that it's not terribly intuitive, and is something that we on the list tend to go over a couple of times a year because the newbies don't understand it, but it _is_ preferable to not placing the variables in rc.custom at all, or completely destroying the rc.init system

of

global changes as you suggest.

It would be convenient to have the choice at installation time.

The _simplest_ fix is to add this to the to of .etc/rc.custom in the distribution:

# Default values are commented with one "#", non-default with "##"

That would be helpful although I am sure that this will not prevent similar questions. I would like to have a configuration file which is easier to understand and to read with other programs. It's handy if you can unset a variable without an equal sign but it's kind of weired and you are getting difficulties if you have to parse such files. I wrote a tool for the remote list configuration and it was much easier for me to pre process rc.custom and remove all the the single/double hashes and the variables without equal signs than to find a way to handle it unmodified.

I think configuration files should have a clear syntax. rc.custom/rc.init aren't such files.

Werner