[569] in Release_7.7_team
Re: New options for add
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Jun 3 14:50:00 1996
To: Craig Fields <cfields@MIT.EDU>
Cc: ghudson@MIT.EDU, release-team@MIT.EDU
In-Reply-To: Your message of "Mon, 03 Jun 1996 14:45:49 EDT."
<199606031845.OAA16171@mad-scientist.MIT.EDU.MIT.EDU>
Date: Mon, 03 Jun 1996 14:49:27 EDT
From: Greg Hudson <ghudson@MIT.EDU>
>> Rationale: "add -f" is fairly useless right now except in your
>> dotfiles, since it doesn't have any reliable behavior unless you know
>> what path you started with.
> I don't agree. This implies that lockers which are for some reason
> desirable in the front of the user's path have usually already been
> previously added to the tail. I would imagine that most lockers that
> need to be in the front of the user's path are useless unless there,
> and so never would have been added to the tail to begin with;
> instructions for using the locker would have already said to do an
> add -f.
This just isn't so. Many lockers (sipb, gnu, outland, watchmaker, and
others) are useful both at the tail and at the head of your path.
It's currently common on -i help for someone to recommend "add -f
locker; program" and have to be corrected because the user may have
already added the locker.
I'm actually not familiar with any lockers which are only useful at
the head of the path.
> The reason I didn't want -m to be the default was because it does
> add a few sed invocations for a feature which some people may not
> care about (although I've realized I can cut the number in half of
> what I have now).
I don't think we need to worry about this for the add -f case.
