[570] in Release_7.7_team
Re: New options for add
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Jun 4 19:02:59 1996
To: Mike Barker <mbarker@MIT.EDU>
Cc: release-team@MIT.EDU
In-Reply-To: Your message of "Tue, 04 Jun 1996 11:18:24 EDT."
<199606041518.LAA26633@megara.MIT.EDU.MIT.EDU>
Date: Tue, 04 Jun 1996 13:27:08 EDT
From: Greg Hudson <ghudson@MIT.EDU>
> 4. One way to rephrase the question is to consider whether there is
> ever a good reason to fail to move the locker. I.e., if "add"
> always moved the locker to the end and "add -f" always moved the
> locker to the beginning, would anyone lose?
I think it's poor for "add lockername" to be treated as a negative
statement about the locker, making it less likely for the next command
to be run from that locker.
We have, under my proposal:
add lockername "Make sure this locker is in my path"
add -f lockername "Make sure this locker is the most important
thing in my path"
add -r lockername "Take this locker out of my path"
I really don't think we need a "Make sure this locker is the least
important thing in my path." The only situation anyone has come up
with for when it would be useful is when you have a conflict between
two lockers and want to resolve it by pushing one of them farther back
instead of pulling the other one forward or simply eliminating the one
you don't want. I've never heard of anyone wanting to do that. And
in that rare case, "add -r lockername; add lockername" would suffice.
Appealing to "symmetry" is not, to my mind, a good argument. We have
"add -f" because it's common to want to make a locker the most
important thing in your path. It is not common to want to make a
locker the least important thing in your path, and my proposal does
not make it exceptionally difficult to do it, so there's no point in
having an option for that purpose.
