Date: Sun, 12 Jul 1998 03:14:35 -0500 (CDT) From: Joel Ray Holveck <joelh@gnu.org> To: winter@jurai.net Cc: cyouse@artemis.syncom.net, bakul@torrentnet.com, dchapes@ddm.on.ca, rminnich@Sarnoff.COM, hackers@FreeBSD.ORG Subject: Re: Improvemnet of ln(1). Message-ID: <199807120814.DAA01115@detlev.UUCP> In-Reply-To: <Pine.BSF.3.96.980711211244.10970p-100000@sasami.jurai.net> (winter@jurai.net) References: <Pine.BSF.3.96.980711211244.10970p-100000@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Obviously this guy is on crack. "Adding a warning to stderr is gonna >> break things! Why can't we just leave it alone instead of effecting >> massive change?!?" > You -will- break things if you alter the default behavior. Show me where. I have already offered to buy a beer for somebody who can show me where I -will- break things; see message-id <199807111926.OAA14413@detlev.UUCP>. > As you are not able to prove for -all- cases that this change will > not break things it should be only enabled by a new switch. (-w as > someone suggested) Neither were we able to prove that there wasn't some assembly code that references errno when we changed it to *__errno(). Neither were we able to prove that nobody's scripts used hexdump and examined an executable file to find information about an a.out image, but we still are going to elf. Neither were we able to prove that adding a #warning to sys/dir.h wasn't going to break things. For nearly any change you make, there will *potentially* be some code, somewhere, that relies on the old state. But nevertheless, if it is unlikely enough to break things, then we make the change and move on. If you want to ensure that anything you might possibly be running will still work after you upgrade, I suggest that your next upgrade from, say, 2.2.6-RELEASE be to... you guessed it... 2.2.6-RELEASE. > Besides, creating a link to a non existent directory is not cause for an > error condition; you get the error when you attempt to reference the link. I'm not talking about an error condition. I am talking about a diagnostic. We're going through a different transition, not dumping to a trap state. > This is the correct unix behavior, to assume that you know what you're > talking about. If you want to have unix perform sanity checks, there are > flags for that as well. Add this as a new flag please. Sorry, I didn't realize that Unix was supposed to never mention if a user is doing something odd. Regrettably, we have a number of programs which violate this important design principle. I'll have to submit a few pr's: pwd_mkdb: Issues a warning if the root's shell is not yet listed in /etc/shells. If, for instance, a user wants the root shell to be only availible as a login shell to root, then it would not be listed in /etc/shells. However, this means that many userlist maintainance programs will issue a diagnostic that is unnecessary and poor design. swapon: Warns if a device is already being swapped on. This is superfluous output in scripts which are executing swapon to assert that all devices that should be swapped on, are being swapped on. This superfluous output should be removed. Users who want to tell if a device is being swapped on when they execute the command should simply add a shell script to their path that executes swapinfo and grep, and gives the appropriate diagnostic. cp: Warns if: 1) a directory is referenced without -R, or 2) a source file is linked to its destination. Obviously, if you had a directory you want to copy, you would have included -R. Also, if a large static file in a compile directory was linked into a build directory, the cp that takes place during the build process would issue an unnecessary diagnostic that disrupts the appearance of the build process. ftp: Warns if an unknown keyword is encountered in .netrc for the target machine. Since comments are not allowed in .netrc, then a user might use an invalid field as a comment. If a script is examining the ftp output, then the extraneous output would confuse it. od: Generates an extra warning about being depreciated if an illegal flag is used. A utility to generate a summary of flags for all programs may intentionally use illegal flags to get summaries from various programs, and the extra line may confuse its parser. lex: -w (suppress warnings) is not the default. This causes warnings in several possible non-error situations. This extraneous output is irrelevant and shouldn't be displayed unless requested. login: Displays a notice if a password is about to expire. This may break autologin scripts which depend on a particular sequence of events. If a user wants to know about password expiration, that information should be displayed by the user's .profile (or equivilent). Most Kerberos-enabled programs: Warn if they cannot connect to a Kerberos domain. make: Warns if it cannot chdir to MAKEOBJDIR (or its equivilent). Clearly, if a user decided to set this to a path the user did not normally have access to, it was intended to only be used if the user were su'd. This superfluous warning should be removed. rsh: When Kerberos-enabled, and connecting to a non-Kerberos host, rsh issues a warning. This warning may break automated login scripts written for pre-Kerberos rsh. units: In the case of a control file which redefines a prefix, will issue a diagnostic. This is undesirable, as such a control file may exist for interoperability with a units-like system with more advanced prefix handling that allows the redefinition of units. Furthermore, this could break scripts which depend on the output of units, and is not useful to the interactive user (who already knows this information). This diagnostic should be removed. write: Issues a warning if a user is logged in more than once and no tty is specified. A script written for a different write may examine stderr and assume that the user is not logged in if anything is sent. This diagnostic should be removed. cdcontrol: Issues a warning when using the default CD device. This warning goes against correct Unix behavior (as described by Dodd, et al) and should be eliminated. ed: Prints a '?' warning if a user makes a typo. An experienced user will know that a typo has been made and will not require a diagnostic. This extra verbosity is unnecessary and clutters up the screen. moused: Issues a warning if the mouse connected has a different protocol than specified. rcp: Warns if setting the TOS for the socket failed. However, since this is not a fatal situation, this diagnostic is superfluous and should be avoided. Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped 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?199807120814.DAA01115>