renew shouldn't be implemented as a shell function

[geofft]

Shell functions are annoying for a couple of reasons:

• If your dotfiles are broken, you don't get them
• If you just installed Debathena and didn't start a new shell, you don't get them (this means you can't "renew" and then "blanche $USER -a debathena-announce" right after installing)
• tcsh has not yet died in a fire but deserves to

The reason that renew is a shell function (or alias in tcsh), as I understand it, is to avoid any chance of it searching your path, which might start with a directory in AFS, which might under some circumstances make you very marginally sad if you don't have tokens. But this is easy enough to work around by making it a shell function/alias that just runs /bin/renew to shortcut the path lookup.

[geofft]

Anders says it should be /usr/bin/renew instead of /bin/renew. I don't particularly care, but I suggested /bin because

   consult / debathena / mitchb  11:52  (I'm going to go get a job.  I'll be back in 10 minutes.)
       Yeah, but in the old days, /usr/bin/renew probably would've been on
       the packs anyway.  Probably in a world-readable place, but for all I
       know, maybe a lot of stuff used to be authuser-only.
   consult / debathena / geofft  11:52  (Geoffrey Thomas)
       "Fine, /bin/renew"
   consult / debathena / geofft  11:53  (Geoffrey Thomas)
       (In an environment with packs, renew probably wants to be in /bin
       anyway.)

I guess we have no plans to use packs ever again, so whatever.

[andersk]

These days, we care more about what the FHS says than how we would have done things in the ancient days with packs.

The FHS says “/bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). It may also contain commands which are used indirectly by scripts.”. ‘renew’ is neither of those.

We also don’t have any backwards compatibility reasons to put it in /bin.

[geofft]

I was taking FHS into account, and thinking about the case that the "other filesystems" needed tickets / tokens / other appropriate authentication for you to be able to mount them, but more problematic for that reasoning is that kinit and aklog are in /usr/bin. On the other hand, fsid is in /bin.

[andersk]

Even in that hypothetical world, you cannot possibly ever need tickets/tokens to mount /usr, because it’s a system-wide filesystem, and also because /usr/bin/kinit and /usr/bin/aklog live inside it.