Date: Sat, 11 Jul 1998 02:08:46 -0500 (CDT) From: Joel Ray Holveck <joelh@gnu.org> To: dchapes@ddm.on.ca Cc: rminnich@Sarnoff.COM, hackers@FreeBSD.ORG Subject: Re: Improvemnet of ln(1). Message-ID: <199807110708.CAA10210@detlev.UUCP> In-Reply-To: <19980711014852.14739@ddm.on.ca> (message from Dave Chapeskie on Sat, 11 Jul 1998 01:48:52 -0400) References: <199807101738.KAA12014@hub.freebsd.org> <Pine.SUN.3.91.980710162309.26548A-100000@terra> <19980711014852.14739@ddm.on.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807110708.CAA10210>