[M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig

[hendrik at topoi.pooq.com]

On Mon, Aug 03, 2009 at 10:21:36PM +0000, Jay K wrote:
> 
> I'm on the fence wrt environment variables.
>  
>  
> It is fairly rare for users to run executables by full path.
> $PATH search and changing $PATH seems to be the way.
>  
>  
> But what paths code tends to use, not sure.
> It might also be blurry as "code" that runs stuff is initially users coding up their command lines in sh and then gradually formalizing things, and "formal" might or might not mean using full paths.
>  
>  
> On Windows, there is no /usr/include.
> You either set $INCLUDE and $LIB and/or you give paths to the 
> compiler/linker on the command line. Or a mix.
>  
>  
> Environment variables are The way to set something and have it be 
> inherited by child processes, but not inherited by the rest of the 
> system.
>  
>  
> They lead to a process tree that works in one setup/configured temporary way.
> But don't lead to an overall system that works a particular way, 
> unless you set them somewhere with enough impact.
>  

That is exactly the mad scientist whill want when he's tinkering with 
deviant Modula 3 compilers.  But it's not what the average user will 
want.  And it's not what the mad compiler tinkerer will want when he's 
just compiling ordinary programs.  So let an environment variable 
override whatever else would be used to find the configuration file.  
And leave it undefined for the average user.

>  
> There is a larger problem in software wrt how to handle "settings".
> There are environment variables. There are lots of text files in 
> /etc. There is the Windows registry.
> They all have pluses and minuses. Really, the Windows registry does 
> have pluses.
> The problem is related to just how many settings there are.
> The more you need, the more general a solution is needed, and the less 
> satisfactory it is bound to be.
>  
>  
> It is far more complicated than most people realize.
> "settings" are contextual. They can be per user, per machine, per 
> user+machine combination, and more.
> I'm sure people will claim "but such and such system solves it all", 
> and maybe, but unlikely imho.
> I mean, heck, per user but I have multiple machines.
> How do I instantly change all my machines to use an orange desktop?
>   Oh, well, there are "roaming profiles" on Windows and networked 
> $HOME directories on Windows. Maybe. But I've basically never used 
> them, so maybe they do solve it?

Let the user provide a program that, when run, will write the 
configuration file to stdout?  Let the user provide a web page with an 
applet that ....
etc. etc.

>  
> There are also settings that shouldn't be settings.
> My terminal emulation usually doesn't quite work. (Amzazing how much 
> does not work..). I find myself messing with $TERM but I should never 
> have to. And still it doesn't work so maybe I don't have to, the 
> problem is elsewhere..

My terminal won't come up at all unless I first start iceweasel or 
gnucash or Pan (maybe some others).  But messing with $TERM won't fix 
this.  The problem is elsewhere. :-)

>  
>  
>  
>  - Jay