On 01 Apr 2015 18:17, Ruediger Meier wrote: > On Wednesday 01 April 2015, Isaac Dunham wrote: > > On Wed, Apr 01, 2015 at 01:42:56PM +0200, Ruediger Meier wrote: > > > I wonder about some hardcoded binary paths. > > > > > > Example swapon.c: > > > > > > #define PATH_MKSWAP "/sbin/mkswap" > > > > > > There are a two problems. > > > 1. It's wrong. We should use $sbindir from configure. > > > 2. When called from our test-suite it will use a wrong (or > > > non-existend, broken) binary. This happens in test > > > swapon/fixpgsz. > > > > > > The question is how to fix this. > > > > > > I would prefer to use "mkwsap" from the same directory like swapon > > > or to simply execvp "mkswap" from PATH. But don't know if we want > > > this. If we really want to keep a hardcoded sbindir then we would > > > need "#ifdef TEST_PROGRAM". > > > > > > Any comments? > > > > The approach that seems obvious to me (assuming you want to keep the > > hardcoded path) is: > > -add -DSBINDIR="$sbindir" to CFLAGS > > Yes, this would be easy. But my preferred logic would be like this > > If "swapon" was called from PATH then just take mkswap from PATH too. > If "/whatever/path/swapon" was called then look for mkswap in the same > path. > > Maybe both cases also with or without fallback $sbindir, /sbin or $PATH. > > I guess we should agree how somthing like this should be handeled in > general. "eject" is also using hardcoded "/bin/umount". seems like $PATH should always be used. if you broke $PATH, well that's your fualt ... tools shouldn't generally be expected to work in the fact of hostile environments like this. -mike
Attachment:
signature.asc
Description: Digital signature