[2800] in testers
Re: sun4 7.7P: add
daemon@ATHENA.MIT.EDU (cfields@MIT.EDU)
Mon Jan 30 22:52:12 1995
From: cfields@MIT.EDU
Date: Mon, 30 Jan 1995 22:51:11 -0500
To: jhawk@MIT.EDU
Cc: testers@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.
> 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. 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.
> 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?
> 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.
> It's option parsing is not 100% robust. For instance:
>> add -v
>add_attach: Undefined variable.
Looks like a bug. :)
> 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.
> Is there some reason that it does
> not simply create a large alias (the semantic
> equivalent of:
> alias add 'set add_opts = (\!:*); '"`cat $initdir/add`"
I see no reason to. You are not invoking add in a loop a hundred
times, and it's still going to be just as fast as any other random
command. And I'm also not at all convinced you can do that.
> $initdir should be evaluated in $initdir/cshrc,
> rather than each time add is called
Why?
> Well, ``env - /bin/athena/tcsh'' is another way, but yes.
I would guess that this is a bug.
> 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.
Craig
