[571] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: New options for add

daemon@ATHENA.MIT.EDU (Mike Barker)
Tue Jun 4 19:09:02 1996

To: release-team@MIT.EDU
Date: Tue, 04 Jun 1996 11:18:24 EDT
From: Mike Barker <mbarker@MIT.EDU>


More discussion material

1.  Some people use "add" to merely mean "put this locker in my path".
They are not concerned about order, and the current functionality of
add is completely sufficient for their purposes.  I.e., they do not
expect it to move the locker.

However, when people use "add -f", they are clearly expecting that the
locker will be moved to the front of the path, whether or not it is
currently in the path.  The current functionality fails to meet their
expectations.

To serve these users, "add locker" should remain with the current
functionality.  "add -f locker" should be changed to always move the
locker to the front.

2.  Other people expect symmetry in the options.  Building up a
command line out of several options is acceptable, as long as the
operation of each option is clear.  For these users, one possible
matrix of possible functions (and commands) is:

			if not in path	    always
	move to front	   add -f         add -m -f
	move to back	   add -b         add -m -b

This allows "add" to be tailored to the user's preferences just by
adjusting the "add_flag" environment setting.

3.  The set of functions seems to be:

			if not in path	    always
	move to front	   
	move to back	   

The question is whether all four functions need to be available for
users, and which ones should be invoked by the basic options ("add"
and "add -f").

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?


home help back first fref pref prev next nref lref last post