Date: Sun, 12 Jul 1998 00:38:58 -0400 From: Bakul Shah <bakul@torrentnet.com> To: joelh@gnu.org Cc: hackers@FreeBSD.ORG Subject: Re: Improvemnet of ln(1). Message-ID: <199807120438.AAA03097@chai.torrentnet.com> In-Reply-To: Your message of "Sat, 11 Jul 1998 14:26:12 CDT." <199807111926.OAA14413@detlev.UUCP>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807120438.AAA03097>