> Then clearly dump and restore should be generating "/etc/rmt". Your
> tape drive might, after all, be on an older host where rmt really is
> /etc/rmt and nothing else. However, if that host doesn't have an
> /etc/rmt, but would have found rmt in the path...

right.  the question is whether the relevant standards (an RFC,
perhaps POSIX) specify that it _must_ be /etc/rmt.

> I'm pretty sure that in the past dump and restore sent "/etc/rmt" and
> that therefore someone has deliberately made the change to "rmt".

This is true.

> The
> only reason I can speculate for this is that "/etc/rmt" is deprecated,
> and rmt is now expected to be in the path.

It could be that they decided to change it on the assumption that rmt will
be in the path everywhere, but i can't comment on the validity of that
assumption, because i don't have the relevant RFC handy (and don't
even know which it is...)


>  > In terms of what it accepts, for root, 'rmt' and /etc/rmt will be
>  > accepted (as /usr/sbin is in the standard root .profile's path). 
>
> Sorry, no.  Well, it *is* in the .profile, but as I noted in the PR,
> that doesn't help because it's not a login shell spawning the rmt. It
> works when root's shell is csh (because the path is also in root's
> .cshrc), but not if it's sh.

yeah, i noticed you mentioned this in your pr, after i sent my mail.
"oops."  8-)



chris