On Fri, Sep 11, 2015 at 10:14:38AM +0200, Andreas Henriksson wrote: > We can't have it both ways. Some people want PATH to be used instead > of hard-coding paths to search for fsck.* helpers, now you report > that passing an incorrect PATH will not work and you want it > hard-coded.... I'm inclined to reassign this bug report to cryptmount > saying it should pass a valid (or unset!) PATH.
Should the caller of /sbin/fsck need knowledge about the other paths where the various fsck.* programs might lurk? It knows where /sbin/fsck is, and that's all that should matter. It could even be argued that implicitly trusting the PATH might be a security problem. If btrfs wishes not to follow the rest (and put its admin tools in /bin rather than /sbin, with no compatibility symlinks), it's broken too. Incidentally, your suggestion of unsetting PATH means that btrfs filesystems can't be checked by /sbin/fsck. -- Paul Martin <p...@debian.org>
