KDE refuses to start, part 2

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

On Thu, Feb 20, 2003 at 04:42:29PM -0500, John Abreau wrote:
> Greg Galperin <grg22 at ai.mit.edu> writes:
> > 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
> 
> First of all, bash is essentially a superset of the bourne shell, and 
> is expected to run bourne shell scripts correctly. "noclobber" is not 
> part of the bourne shell, and scripts written for that over the past 
> 30+ years shouldn't have to be rewritten to account for this. 

If it's bourne shell compatibility you want to talk about, they have
done some things to try to solve this problem.  The bash man page
says:

       If  Bash  is invoked as sh, it tries to mimic the behavior
       of sh as closely as  possible.   For  a  login  shell,  it
       attempts  to  source  only /etc/profile and ~/.profile, in
       that order.  The -noprofile option may still  be  used  to
       disable  this  behavior.   A  shell invoked as sh does not
       attempt to source any other startup files.

If you write a script which assumes 'sh' behavior and features, run it
as an 'sh' script.  If you write a script which assumes 'bash'
behavior and features, run it as a 'bash' script and code it so that
it works -- even if the user has a different default parameter setting
in their shell than you do.



> Second, your argument applies to any other baby-proofing options that 
> might be added to bash in the future. I don't agree with the argument 
> that a script I wrote in 1985 is badly coded merely because it fails to 
> explicitly check for an environment variable that will be added to bash 
> in 2005.

>From your "baby-proofing" comment I gather you disapprove of this
noclobber.  I happen to disagree on this particular setting(*), but as
you point out your comments apply to pretty much any shell setting.

In this case I don't think the scripts which started the discussion
were written in 1985, so they lose this particular excuse.  But a
script which was might (reasonably, IMHO) need some updating; features
are added, changed, and are deprecated as time goes on and new
versions of things like shells are developed.  While it might have
been coded well in 1985, it might be out of date now.  Unless you have
some explicit versioning (something better than is built into bash!)
in your shell, you shouldn't expect it'll work for eternity (20
years!) on whatever happens to be called "bash" at the time.  (Reminds
me of C.A.R. Hoare's famous quip "I don't know what the language of
the year 2000 will look like, but it will be called Fortran" -- even
old languages change in non-backwards-compatible ways over a time
scale of decades.  Expect it, accept it.)

If users are "required" to have only the default bash settings, or
worse, only the default bash settings from 1985, then you've basically
mandated stagnation.  ("required" in the sense of "required to be able
to run standard tools and do useful things on the system.")  Yes,
features are added, and (at least in some cases :) that is a good
thing.  If you require users not to use the new features, then you
render the feature useless; it might as well not be there.  I also
personally don't think random shell scripts should be dictating the
configuration of my interactive shell by "prohibiting" me from using
standard configuration features.

You're surely right that you can't anticipate new features and there
will invariably be breakage as new versions are phased in; but
software needs to be maintained, and we shouldn't expect backwards
compatibility with 1985 any more.

(*) "noclobber"-style war story: I once had a sysadmin accidentally
wipe out hundreds of gigabytes of home dirs by typing "mke2fs -j"
instead of "tune2fs -j".  He knew instantly, as he was hitting the
return key.  A prompt like "are you sure you want to irreversibly
destroy these hundreds of gigabytes?" would have saved a whole lot.
There are times and places when prompting is useful.  I'm not asking
*you* to turn noclobber on; just give me the option and let me turn
it on if I want -- even if I want to use some standard tools too!
("Ha ha, he fell for the booby trap and actually tried to use that
feature we provided! Sucker! Ha ha ha!")



On Thu, Feb 20, 2003 at 03:58:06PM -0500, Jeff Kinz wrote:
> > 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

However, noclobber has existed in bash since literally the eighties.
I'd personally prefer to have a better environment than I was running
in the eighties.  I also think the grace period for noclobber has
expired (especially so for projects which were started in the nineties).



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

And this might be the heart of the problem: we're using this
"deliberately non-interactive" shell language for nearly all of our
interaction with UNIX.  They try to hack around this dual role a bit
by giving the separation of dotfiles between "sh" and "bash"
invocation, but that's not good enough -- what if I really want to
write a bash shell script?

(BTW, when I want to overwrite a file and I'm sure of it I use >| (or
>! in csh/zsh); when I want to be more careful I use > alone.  With
noclobber set I get both of these options; without it I only have one.)



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

How do you find and fix any bug, security hole, or design flaw?
For one, you let people report the problems (which was one of the
questions that started this thread).  And yes, you recode and
re-release and distribute new versions.  And yes, in the case of free
software, for free.  And the amazing thing is that this process works!
But it starts with people reporting the problems they find...



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

I disagree -- I want to support one primary design feature of UNIX,
which is its customizability and flexibility.  If I wanted "there's
only one way to do it and we'll tell you what it is" I'd be running
MacOS (v9) or Windows or something like that.



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

FWIW, I've been using noclobber in csh/tcsh since the eighties (not
sure exactly when), and it hasn't been a source of problems for me.


--grg