KDE refuses to start, part 2

[Jeff Kinz]

On Thu, Feb 20, 2003 at 03:00:12PM -0500, Greg Galperin wrote:
> > > You seem to be saying that as soon as I change any default or set any
> > > environment variable, I'm no longer in a "normal UNIX-style environment,"
> > > and I shouldn't expect anything to work any more.  
> > 
> > No, I absolutely didn't say that.  Are you sure you're responding to the 
> > right email?
> 
> 
> Hey, Jeff -- be nice.  Being obnoxious or snide is unlikely to result
> in a productive discussion.  [Other such comments cut out below.]

You're right, I apologize.  You caught some fallout from events occurring
on the RedHat Open Source Now list which is being deliberately damaged 
by an *hole who spends his entire day being deliberately dense or lying to
prove his points.  His proposal is that there should be only one version of
Linux.  I guess he intends to wave a magic wand and make the GPL disappear? 
And the net result is damaging the Open Source/Linux movement.   
(I did mention it had become a hot button. :-)

> Trying to bring some focus, you think that it's reasonable for scripts
> to assume that the user didn't customize noclobber, 

Yes, very reasonable.  The default setting for noclobber is off.  And for 
many years the noclobber option did not exist in any of the shells. As a
result there is a huge body of tools which depend on it not being set,
especially system administration tools.  It first appeared in the "C-shell"
and was not part of any version of "sh" for many many years.  Even though
"C-shell" was my personal favorite for command line interaction, "C-shell"
was considered harmful.  It was widely prohibited from use as a system level
scripting language.

The noclobber option was created, to protect users who just couldn't
believe that the shell would let them just overwrite a file without asking
"Are you sure you want to do that?".  Both Thompson and Ritchie have stated 
several times that their intended design was "noclobber off".  Remember
UNIXEN command line commands aren't supposed to say anything unless
something goes wrong.  They are deliberately terse and deliberately
non-interactive.  "Noclobber on" breaks this and breaks all the scripts which
depend on it.

> one of the twenty
> (give or take, depending on your shell version) bash "shell options."
> I disagree.  Those twenty shell options are there explicitly so the
> users can customize them, and I believe it's a bad assumption and poor
> coding to assume they haven't been customized -- especially when
> there's an easy fix like adding the one line "set +o noclobber" to a
> script which needs it set in a particular way to work.  

Yes this is a theoretically possible fix but realistically impossible.
How are you going to find every instance of every script in the world which
might be affected by this? And then recode them and get the products they are
part of re-released and distributed to the customers ? For Free ?  And
remember, this affects all UNIXEN, not just Linuxen so you also have to go
and fix ALL of the closed source products in the world.

Basically, you're trying to recode the world because you want the inherent
design philosophy of UNIX to change.  It's not going to happen.

> Well, you certainly said that setting noclobber "destroys the normal
> UNIX environment," but gave no indication that this particular setting
> was unique in this respect.  

> You also gave no explanation why this is the case 

Hmmm - I thought that this explained why: (from my prior email)
############################################################
Setting "noclobber" creates a local deviation from the normal
UNIX behavior of "let the user do what they want".

If you block this behavior you are preventing all scripts and programs which,
rationally expect this to behavior to be valid, from working correctly.

It is a fundamental principle of the UNIX design/"way of doing things" 
just like "In all cases, do something reasonable."
#####################################################################

> because any bash shell option related to
> command-line syntax must be left at their default setting in a "normal
> UNIX environment."  When educating others, it helps to give them the
> tools to make appropriate generalizations and avoid inappropriate
> ones.
> 
> To make it worse, I'm not sure what you mean by a "normal UNIX
> environment."  Is there some specific document you're referring to
> that defines what this is, perhaps some specific UNIX standard?

A "normal" UNIX environment is one which has "noclobber" set to "off". :-)
There may be other things you should leave at their default as well.

I'm not aware of other shells options which deliberately break the 
UNIX design philosophy.  I ran into clobber in the "C-shell" around 1984
or so, used for about a half a day, and then put it away forever.
It breaks tons of stuff. (I think it may be evil :-) )

> 
> If there is one you have in mind, I'd be surprised if it makes any
> statement about bash at all, much less prohibits users from using its
> standard configuration options (including noclobber).
> 
> Because of this, I did assume that by "normal UNIX environment" you
> just meant "a UNIX installation with 'all the default settings'
> (whatever that might refer to, but which would include a bunch of bash
> shell options)."  I now know from your email that this is not what you
> meant, but I still don't know what you had in mind when you referred
> to a "normal UNIX environment."
> 
> 
> 
> > Setting "noclobber" creates a local deviation from the normal
> > UNIX behavior of "let the user do what they want".
> 
> On the contrary -- allowing a user to customize their environment is
> exactly following the philosophy of "let the user do what they want."
> And one of the standard twenty customizations provided by bash is noclobber.

And I Also said :
>>>Of course part of the UNIX principle of "let the user do what they want"
>>>also means letting them break the environment!  :-)   But then they are 
>>>responsible for the results.

The results will be that many things that used to work will no longer work.
If the user doesn't mind that then its OK for them to use that option, if not
then they should leave it on the default setting.

> > If you block this behavior you are preventing all scripts and programs which,
> > rationally expect this to behavior to be valid, from working correctly.
> 
> Technical point: I think this bash shell setting would just affect
> bash scripts, not "programs" in the general sense, yes?

Bash has become the spiritual successor to "sh".  "sh" is the scripting tool
which many other high level UNIX tools is built on.  For example, the scripts
which run at system boot time are "sh" (or "bash") scripts.  If they stop
working you will be in severe pain. 

> > > Another possible fix would be for bash scripts which require a
> > > particular setting of 'noclobber' to explicitly set it as required.
> > > Given that people do customize their environments, this would seem wise.
> > 
> > Hmm - re-write every shell script in existence to check for and unset
> > noclobber?  Sounds expensive!  :-)
> 
> Actually, I'd advocate careful coding if the first place to avoid the problem.
> Sounds expensive?  Well, yes, in the sense that making robust software is
> expensive, making software without gaping security holes is expensive,
> and making software without massive numbers of bugs is expensive.
> 
> (Technically, you don't need to check for it -- just unset it at the
> top if your script depends on it.)
True.
> 
> > > > Did you set noclobber because you are worried about using rm with wildcards?
> > > 
> > > Not speaking for the original poster, I set it because I don't want to
> > > lose a file by redirecting to the same name.  (Does the noclobber
> > > setting affect rm?  How?)
> > 
> > rm is unaffected by the noclobber setting, but I have seen people alias
> > rm to behave like it has a noclobber setting so that it will prompt the user 
> > and ask if they want to delete each file.  This also breaks many scripts.
> 
> OK, then I'm not sure I understand your original question here.  If rm
> is unaffected by the noclobber setting, why would someone set
> noclobber because they're worried about using rm with wildcards?

People who set noclobber generally also alias rm to "rm -i".

-- 
Jeff Kinz, Emergent Research,  Hudson, MA.  "jkinz at rcn.com" 
"jkinz at ultranet.com" copyright 2003.  Use is restricted. Any use is an 
acceptance of the offer at http://users.rcn.com/jkinz/policy.html.