Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 16 Apr 2020 11:38:40 +0200
From:   Lukas Czerner <lczerner@redhat.com>
To:     "Theodore Y. Ts'o" <tytso@mit.edu>
Cc:     linux-ext4@vger.kernel.org
Subject: Re: [PATCH] e2scrub: Remove PATH setting from the scripts
Message-ID: <20200416093840.y5w2azeivn6mhbnu@work>
References: <20200402134716.3725-1-lczerner@redhat.com>
 <20200410161635.GP45598@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200410161635.GP45598@mit.edu>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

On Fri, Apr 10, 2020 at 12:16:35PM -0400, Theodore Y. Ts'o wrote:
> On Thu, Apr 02, 2020 at 03:47:16PM +0200, Lukas Czerner wrote:
> > We don't want to override system setting by changing the PATH. This
> > should remain under administrator/user control.
> > 
> > Signed-off-by: Lukas Czerner <lczerner@redhat.com>
> 
> The reason why the PATH was added is because most users don't have
> /sbin or /usr/sbin in their PATH, and if they run "sudo e2scrub",
> finding commands like lvcreate, lvremove, et. al., wouldn't be there.

I don't understand, e2scrub should be in be in sbin as well, right ?
Besides what if such user wants to run lvcreate, or lvremove ? This
seems like a problem that should be fixed somewhere else.

> 
> I suppose we could do something like
> 
> PATH=$PATH:/sbin:/usr/sbin

that's better than replacing it.

-Lukas

> 
> instead, but otherwise, users will see some unexpected failures.
> 
> 	     		      	       	    	       - Ted
>