From owner-freebsd-hackers Sat Jul 11 21:39:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA01553 for freebsd-hackers-outgoing; Sat, 11 Jul 1998 21:39:03 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA01542 for ; Sat, 11 Jul 1998 21:39:01 -0700 (PDT) (envelope-from bakul@torrentnet.com) Received: from chai.torrentnet.com (chai.torrentnet.com [198.78.51.73]) by torrentnet.com (8.8.5/8.8.5) with ESMTP id AAA03769; Sun, 12 Jul 1998 00:38:59 -0400 (EDT) Received: from chai.torrentnet.com (localhost [127.0.0.1]) by chai.torrentnet.com (8.8.8/8.8.5) with ESMTP id AAA03097; Sun, 12 Jul 1998 00:38:58 -0400 (EDT) Message-Id: <199807120438.AAA03097@chai.torrentnet.com> To: joelh@gnu.org CC: hackers@FreeBSD.ORG Subject: Re: Improvemnet of ln(1). In-reply-to: Your message of "Sat, 11 Jul 1998 14:26:12 CDT." <199807111926.OAA14413@detlev.UUCP> Date: Sun, 12 Jul 1998 00:38:58 -0400 From: Bakul Shah Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> How on earth will issuing a diagnostic break scripts? > > Consider a script that uses output of another script. A > > typical shell script that just does its job normally does not > > chatter away on stderr. > Most scripts that I have seen that rely on output use stdout, not > stderr. Most. Not all. Regression test scripts e.g. would want to capture all output. An expect(1) script may want to try different things depending on the kind of error message it gets. > >> How on earth will issuing a diagnostic make it harder to write > >> scripts? > > Because now you have to filter out (additional) noise. > So, we've now got a script that relies on the stderr of another > script, the latter of which makes symlinks to non-existant files, and > the former of which will break if a line is added. Have I got you > right? Nope! I am arguing on general principles, not about a specific one line warning. Consider: - The same script may behave differently on FreeBSD from other Unix compatible OSes. - In ln -s you can warn and do a reasonable thing. Not so for other commands. For instance the following sort of warning is not very helpful (even if you did not intend to overwrite target). $ cp source target cp: warning: you just overwrote `target' In general, fat fingers at 4AM can cause all sorts of mistakes you can't easily warn against/prevent. - There is nothing to prevent one from removing a symlink target file later (causing the same problem you are trying to warn about) and warning about *that* is not going to be cheap! > >> I'm *not* talking about a prompt a la cp -i. I'm *not* talking about > >> a failure a la trying to symlink over an existing file. I'm talking > >> about a diagnostic. > > Understood. I am just pointing out that *any* deviation from > > existing practice can break things. > > If you want every utility and library call to behave the same forever, > then stay at the same OS revision forever. If you don't want > change... don't change. The issue is to not make a silent change. Principle of Least Astonishment and all that. As a rule one would want to break compatibility with existing practice _only if_ a) there is a *significant* improvement and b) there is *no* other way. > I realize that it is possibly feasable for such a script to exist. Amen! -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message