From owner-freebsd-hackers Sat Jul 11 00:15:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA06562 for freebsd-hackers-outgoing; Sat, 11 Jul 1998 00:15:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from merlin.camalott.com (root@merlin.camalott.com [208.229.74.19] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA06554 for ; Sat, 11 Jul 1998 00:15:32 -0700 (PDT) (envelope-from joelh@gnu.org) Received: from detlev.UUCP (tex-94.camalott.com [208.229.74.94]) by merlin.camalott.com (8.8.7/8.8.7) with ESMTP id CAA10001; Sat, 11 Jul 1998 02:10:24 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.8) id CAA10210; Sat, 11 Jul 1998 02:08:46 -0500 (CDT) (envelope-from joelh) Date: Sat, 11 Jul 1998 02:08:46 -0500 (CDT) Message-Id: <199807110708.CAA10210@detlev.UUCP> To: dchapes@ddm.on.ca CC: rminnich@Sarnoff.COM, hackers@FreeBSD.ORG In-reply-to: <19980711014852.14739@ddm.on.ca> (message from Dave Chapeskie on Sat, 11 Jul 1998 01:48:52 -0400) Subject: Re: Improvemnet of ln(1). From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <199807101738.KAA12014@hub.freebsd.org> <19980711014852.14739@ddm.on.ca> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Actually, why not just have ln warn of questionable links in any case. > Please NO! I like that most standard unix commands do what I tell them > even if I tell them the wrong thing. It puts the onus on me to think > about the commands I give. Nobody's talking about making Unix not letting you do either stupid or clever things anymore. We're not even talking about making it harder. See below. > (Unlike in m$. How many people do you know that habitually close > editor windows before saving expecting the system to notice and > remind them to first save the file? I know quite a few). Unlike Unix, where we have thrived for years on ex, everybody's favorite text editor: if (F_ISSET(ep, F_MODIFIED) && ep->refcnt <= 1 && !force) { msgq(sp, M_ERR, "264|File modified since last complete write; write or use ! to override"); return (1); } Although in these enlightened days, we use the more refined and sophisticated vi: /* Call the ex parser. */ (void)ex_cmd(sp); Or, maybe you prefer Emacs: (save-some-buffers arg t) (and (or (not (memq t (mapcar (function (lambda (buf) (and (buffer-file-name buf) (buffer-modified-p buf)))) (buffer-list)))) (yes-or-no-p "Modified buffers exist; exit anyway? ")) But naturally, we Real Unix Hackers don't use these utilities. Real Unix Hackers use cat for all our manual file creation needs... or would you consider the difference between SIGINT (^C) and EOF (^D) to be a type of confirmation? How about file modification? We'll use ed, the standard text editor. But wait... what's this bit of ed code? gflag = (modified && !scripted && c == 'q') ? EMOD : EOF; Interactive user interfaces for interactive programs are a Good Thing. I for one would rather let my computer remember whether or not I've saved all my buffers than me have to. Humans are fallible, and at 4:00 AM after a long night of hacking, I'm bound to forget to save something. And we all know whether it will be the buffer with 2 changes, 5 changes, or 328 scattered three-character painfully researched and discovered changes. (A related side note: Emacs users who jot useful notes in *scratch* may want to investigate the emacs-lock package in Emacs 20.) But, putting sarcasm aside for a moment (yes, I can if I try), this isn't relevant to our present case. We're not talking about a prompt in an interactive program. If I read our discussion right, we're talking about adding a warning. # cd /usr # ln -s src/sys /sys ln: warning: src/sys does not exist relative to /. # rm /sys # ln -s usr/src/sys /sys # ^D, with the satisfaction that you have averted another needless help desk call. Unix will still let you shoot yourself in the foot if you want to, and quite gladly let you script the shooting. What we're proposing is a mechanism by which you'll know that you did so immediately instead of first feeling a strange pain in your foot a week later, at the same time as you wonder where your kernel source went. > I've many times used ln(1) to create what you call 'questionable links' > on purpose and I'd _hate_ warnings. You frequently link to files that don't exist? I generally consider that to be putting the cart before the cat(1), er, horse. But it's your system. > If someone insists on adding such warnings then do it like mv(1) and > cp(1) by adding an option to ln(1) turn it on. You mean, in the style of the cp and mv which both sport -f, and one of which features the -R flag? Bottom line: Warnings are good program design. Requiring extra work to issue them-- particularly when they're most frequently required in interactive use-- is not. One of my very favorite badges says, "Unix doesn't keep you from doing stupid things because that would keep you from doing clever things." That's still true. But I still like to know that I'm doing something stupid, just in case I'm not particularly clever at the moment. 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