Subject: Re: misc/670: sh path does not include /usr/sbin/rmt
To: Chris G Demetriou <Chris_G_Demetriou@LAGAVULIN.PDL.CS.CMU.EDU>
From: Daniel Carosone <firstname.lastname@example.org.OZ.AU>
Date: 01/03/1995 11:47:59
Chris G. Demetriou writes:
> > Fair enough. I know it used to be called /etc/rmt, I had assumed that
> > was deprecated now. Would someone in core care to express a
> > preference on this issue of style, and then we can fix things
> > accordingly?
> my feeling on matters like this is that NetBSD should be as tolerant
> as possible in terms of what it accepts, and as restrictive as
> possible in terms of what it generates.
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...
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". The
only reason I can speculate for this is that "/etc/rmt" is deprecated,
and rmt is now expected to be in the path.
> 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.
> For other users, it's not clear how much we can do; i don't think
> it's wise to be adding /usr/sbin to the default path for other
Agreed. But that's a site configuration problem, because by default
other users don't have perms on the tape devices anyway.