Re: /etc/profile should include sbin in PATH
The original purpose was to provide a place for binaries like system daemons
which lived in /etc to live. The FHS is very clear that the intent is that
people should _not_ have to add those directories to their paths, so we are
prohibited from putting anything there that a user might find useful.
For the long term I propose the following list of programs:
1) System daemons that are normally run from /etc/init.d scripts
2) <package>-config scripts that are normally called from postinst scripts
File system standards shouldn't rely on subjective interpretation of what the
"normal" use of the program is. It should be separated based on something
unambiguous or else the distinction will only engender further confusion and
be useless.
Why is mount in /bin but ifconfig in /sbin ?
Why is netstat in /bin but traceroute in /sbin ?
Why is mkfatimage16 in /usr/bin but mkfs.vfat in /sbin ?
Why is fuser in /bin but lsof in /usr/sbin ?
(For that matter, why is fuser in /bin and not /usr/bin !?!)
There is no consistency to how the current distinction is being made, the net
result being that normal users regularly add sbin to their paths and whatever
benefit sbin may have had is already completely lost.
If sbin is restricted to programs like daemons and configuration scripts then
at least people won't have to add sbin to get access to totally reasonable
programs. Implicitly meaning we've failed to accomplish what the FHS
explicitly describes as the goal of the split.
If people insist then we could add something like this to cover programs like
shutdown. Personally I think it's a recipe for mistakes like ifconfig and
traceroute, but I expect it would be hard to convince people to move shutdown,
mkfs, etc. (Note that mkfs could be usefully used for non-administrative uses,)
3) programs that serve no useful purpose for non-root users such as shutdown
> Most people? I think that you'll find that most people have no problems
> with the current default path. I really do think that you're trying to
> fix a problem that doesn't exist.
No, I think most people swear every time the use a new Debian machine and
redefine their path. That means something's wrong. It was redefining the
meaning of sbin that was an attempt to solve a problem that didn't exist. When
was the last time you heard someone complaining, "it's so confusing seeing
that cryptic `ifconfig' thing in my shell completions" ?
For the short term I still say we should put sbin in the default path, that
solves the usability problem, and leaves us as compliant with the fHS as ever,
which is to say noncompliant only in that useful programs are found in sbin.
--
greg
Reply to: