[2801] in testers
Re: sun4 7.7P: add
daemon@ATHENA.MIT.EDU (John Hawkinson)
Mon Jan 30 23:19:26 1995
Date: Mon, 30 Jan 1995 23:18:56 -0500
To: cfields@MIT.EDU
Cc: jhawk@MIT.EDU, testers@MIT.EDU
In-Reply-To: "[2800] in testers"
From: John Hawkinson <jhawk@MIT.EDU>
> > It requires environment or shell variables
> > to be defined in order for the script to be
> > sourced (initdir).
>
> I don't see a problem with this. The same script that sets initdir
> sets the add alias. If you rip out the initdir variable, then you get
> to fix the add alias.
Herein I delve into programming philosophy rather than "what really
makes a difference". There is no reason, to my knowledge, for the
user to carry this additional shell or environment variable
with their processes; your new add creates such a reason, unnecessarily
in my opinion. Jumping to the end:
> > $initdir should be evaluated in $initdir/cshrc,
> > rather than each time add is called
>
> Why?
Because it's more work. There's no reason to make your code do more
work and take more cpu cycles (albeit imperceptable) unless it makes
the code more readable, or enhances some other quality. I cannot see
that being done in this case.
> > It requires that certain commands be in the user's
> > path, but does not set the path explicitly.
>
> Many pieces of software do this. It's a feature.
In general, I disagree with this qualification. In the case of programs
which do not run as their own processes, but rather share an environment
with other processes (such as those sourced by a shell, such as add),
things are more difficult in that you need to be careful to restore
things as they were.
> You can reset your path and find those things anywhere you want them
> to be found. By hard coding the program locations or PATH variable,
> I force you to hack the code itself in order to make it work if you
> have other desires. This is part of the point of a search path.
I disagree. If your script were to save $path and then set it, perhaps
including the previous search path if you felt that was appropriate (I
don't, but I can think of no strong argument for that sub-position),
then no user would "lose" with your add when they invoked it with a
nonstandard path. Why would a user do so? Perhaps they're the victim
of some athena software that missets their path, like rsh or
somesuch. Perhaps they are trying to avoid hashing AFS directories
unnecessarily, or...
It has been suggested to me that it is a csh bug that PATH is not
set upon invokation whereas path is, but add ought to work around this
bug, if it is a bug. It's not clear to me that it is such...
> > It is a c-shell script, but nonetheless expects PATH to be
> > defined, which is not guaranteed.
>
> It is not guaranteed, but it is a pretty reasonable expectation. Typically,
> if there is no PATH, the user is losing. Conditions where this is the case
> and the user is not losing are conditions where the user is doing weird
> things. Do you suggest it should exit with a message if PATH is not set?
No. I disagree that the PATH is a concept that should be used in
csh programs. csh is far more internally consistant with respect to
$path than PATH. See above.
> > It requires MANPATH be set.
> So do you suggest that it create MANPATH if not set, or ignore doing
> anything to MANPATH if not set? Sometimes there's a point to the
> "What should have happened" field of the bug report form.
I don't know. In response to this, the user who deliberately has
unset MANPATH has two options:
1) set MANPATH
invoke add
2)) set MANPATH
invoke add
unset MANPATH
In light of this, I think it's appropriate for MANPATH to be set by
add. Frankly, I can see it go either way.
> > It's option parsing is not 100% robust. For instance:
> Looks like a bug. :)
Yay! :-)
> > The add alias sources $initdir/add every time it's
> > invoked; I doubt the shell caches this (though AFS
> > probably does).
>
> Yes, AFS does. And if it didn't, this would probably still be
> minor compared to the overhead of a fork and exec of attach.
What's your point? Just because it's minor doesn't mean it's right...
> > Well, ``env - /bin/athena/tcsh'' is another way, but yes.
>
> I would guess that this is a bug.
I'm afraid I'm not sure just what you're referring to. My whole
bug report, or env, or csh, or ??
> > I disagree. PATH is a Bourne thing, path, is a csh thing. csh changes
> > PATH only as a courtesy to Bourne derivatives...
>
> Errr. I strongly suggest you read the exec*(3) manual page. PATH is a
> widely used environment variable, used even by the C libraries. And
> how do you suggest csh pass a path on to a child csh, if not via PATH?
> I suspect that path, the csh thing, is a csh convenience interface
> to PATH, but that is speculation.
I retract my previous position that PATH is a bourne-shell thing
exclusively. I refuse to be a csh expert, were I qualified, but
as best I can tell (since it operates when $path is set and $PATH
is not) it does not honor PATH as other pieces of Unix do, and when
you choose to script within it, you ought respect it.
--jhawk
ps: Throughout this bug report, I use the syntax ``path'' and ``$path''
somewhat interchangeably. This was an attempt to avoid quoting ``path''
in order to refer to the shell variable, whereas capitalization makes
PATH clear. Rest assured, this does _not_ mean I've been corrupted
by perl.
