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 |
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
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |