Date: Sun, 12 Jul 1998 08:58:15 -0400 (EDT) From: Thomas David Rivers <rivers@dignus.com> To: bakul@torrentnet.com, cyouse@artemis.syncom.net Cc: dchapes@ddm.on.ca, hackers@FreeBSD.ORG, joelh@gnu.org, rminnich@Sarnoff.COM Subject: Re: Improvemnet of ln(1). Message-ID: <199807121258.IAA14584@lakes.dignus.com> In-Reply-To: <Pine.NEB.3.96.980711114048.7449A-100000@artemis.syncom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > On Sat, 11 Jul 1998, Bakul Shah wrote: > > > For interactive use, alias ln to `ln -w' to warn you. If you > > change the default behavior of ln, you *will* break scripts. > > Unlike editors, ln is more likely to be used in scripts than > > interactively (well, it is so for most people). > > I fail to see how. An extra line output to stderr is going to break > scripts? Can you provide an example? > > > > Bottom line: backward compatibility is a good program design. > > Well, not always. Compare Windows/DOS. > > > Chuck > Sure... Consider the following files, 'foo' and 'bar': foo: ... do some stuff - with stderr copied to stdout (i.e. 2>&1) one of the 'stuff' commands is "ln" echo "done" bar: if test "`foo`" != "done" then something happened... fi The script was working just fine creating the symlink; with the change 'bar' now reports that something is amis. It is an example of a change in behaviour - which (depending on what 'something happened...' does; could be anywhere from annoying to devastating... Particularly, since the users/authors of this didn't expect the change (i.e. they didn't change 'foo') - Dave Rivers - 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?199807121258.IAA14584>