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