Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

KDE refuses to start, part 2



On Thu, Feb 20, 2003 at 12:07:43PM -0500, Greg Galperin wrote:
> On Thu, Feb 20, 2003 at 11:45:04AM -0500, Jeff Kinz wrote:
> > No.  KDE is expecting a normal UNIX-style environment.  One of the most basic
> > tenets of the UNIX philosophy is "Let the user/program do anything it wants".
> > It is the responsibility of the user/program not to do anything harmful.
> > 
> > An environment with the noclobber option on is a totally different one from
> > the normal UNIX-style environment.  It is more, shall we say "VMS like"?
> 
> 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?

Where did I say that setting any variable or default destroys the normal 
UNIX environment?

Logic does not permit you to take a single case and extrapolate it to
apply to all cases.  Its like assuming all animals bite because
someone got bit by a dog.  Ridiculous.

(Extrapolating like that is a hot button of mine. I causes me to think
the person using it is either being deliberately dense or is dense. :-)
Having been writing on technical issues for years in addition to
developing software for years I have come to value precision and
lack of ambiguity.  If I meant to say something so broad I would 
have stated it broadly.

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."

> 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!  :-)   Yes, people customize their environment.
The ability to customize it is one of the most powerful and useful things about 
UNIX but noclobber is problematic and always has been because it breaks 
the standard UNIX approach.  Almost all other customizations don't.

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.

> > 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.

Granted scripts should use the full path to the command they want just for
security reasons, but again, many, (most ?), don't. 


-- 
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.




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org