KDE refuses to start, part 2

[grg22 at ai.mit.edu (Greg Galperin)]

On Thu, Feb 20, 2003 at 01:16:48PM -0500, Jeff Kinz wrote:
> 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?


Hey, Jeff -- be nice.  Being obnoxious or snide is unlikely to result
in a productive discussion.  [Other such comments cut out below.]

Trying to bring some focus, you think that it's reasonable for scripts
to assume that the user didn't customize noclobber, 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.  (Also, using
>| instead of > for redirection would be another solution.)



While that about sums up the discussion, I guess it would be rude of
me to totally ignore your last email, so I suppose I should respond to
a couple main points.  First off, I freely admit that I do look for
generalizations and further that I do make some bad ones as a result.
Apologies for doing so in this case.


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

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 -- e.g., 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?

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.



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




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




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


--grg