RE: [PATCH] tests: adjust PATH to include /usr/sbin for filefrag-using tests

[Voelker, Bernhard]

Bob Proulx wrote:

Bernhard Voelker wrote:
> > Again, I don't think it is related to sudo. It is /bin/login.
> 
> You didn't use sudo to run those tests?  Okay.  That wasn't
> immediately clear.

Sorry if my wording was not precise enough. The confusion began
because I copied the checkin message of the other checkin:

  * tests/init.cfg (require_filefrag_PATH_): New function to test whether
  filefrag is in PATH, otherwise adding /usr/sbin to PATH.  Needed for
  distributions (OpenSuSE) in which sudo does not include /usr/sbin in
  PATH.

After that I tried to make it clear that I did't use sudo:

* http://lists.gnu.org/archive/html/coreutils/2011-11/msg00090.html:
  I'm not using sudo, I just login to my PC as user "berny",
  then start an xterm, cd to the coreutils directory, and
  "make check".

* http://lists.gnu.org/archive/html/coreutils/2011-11/msg00093.html
  It's not sudo, it's a login at the console or into X.

Well, let's forget about it ... although I think the checkin comment
should be revised - once everybody agreed that the patch should be
applied.

> > I even changed to runlevel 3, renamed sudo, did the login on tty2, and
> > then "make check TESTS=cp/fiemap-perf" was skipped in the same way.
> > Sudo is not used here. And such sbin paths have never been included
> > for non-root users on SuSE and AFAIK on Solaris.
> 
> Wow!  That was above and beyond the call of duty!  And to be
> completely honest it was also completely unnecessary.  The necessary
> words were, "I didn't use sudo.  I just ran it with a default PATH
> that did not include /usr/sbin:/sbin in it."  I don't mean this
> harshly but since there was confusion felt it was necessary to say it
> very plainly.

As I tried 2 times to mention that I didn't use sudo, I was not
100% sure any more if my X session manager was using sudo or not.
So I double-checked again both on a console tty and by renaming sudo
before login. Now I know that it doesn't ;-)

> ... But since many of us always augment our PATH with
> all of the sbin paths all of the time anyway it means that we
> sometimes don't run into problems when other people do.

In my eyes, this is another argument for including both /usr/sbin
and /sbin generally for the coreutils build system.

Have a nice day,
Berny