Hi,
Recently, the value of my PATH variable seems to be messed up:
> [asinha@ankur-laptop ~]$ echo $PATH
> /usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/asinha/.local/bin:/home/asinha/bin
/usr/bin is supposed to come before /usr/sbin etc. This makes mock throw
an er
no, in general /usr/sbin is supposed to come before /usr/bin
and any software assuming the opposite has a bug
look what binaries are in /usr/sbin and then you know you really
don't want in general a bad package override them with place
a binary with the same name in /usr/bin
Am 04.05.2014 18:11,
Reindl Harald wrote:
>no, in general /usr/sbin is supposed to come before /usr/bin
>and any software assuming the opposite has a bug
>
>Am 04.05.2014 18:11, schrieb Ankur Sinha:
>> /usr/bin is supposed to come before /usr/sbin etc.
I don't know of any kind of standard that specifies either. Does P
Am 04.05.2014 18:54, schrieb Björn Persson:
> Reindl Harald wrote:
>> no, in general /usr/sbin is supposed to come before /usr/bin
>> and any software assuming the opposite has a bug
>>
>> Am 04.05.2014 18:11, schrieb Ankur Sinha:
>>> /usr/bin is supposed to come before /usr/sbin etc.
>
> I don'
On Mon, 2014-05-05 at 02:11 +1000, Ankur Sinha wrote:
> Hi,
Hi,
> Recently, the value of my PATH variable seems to be messed up:
>
>
> > [asinha@ankur-laptop ~]$ echo $PATH
> > /usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/asinha/.local/bin:/home/asinha/bin
The same.
Reindl Harald wrote:
>Am 04.05.2014 18:54, schrieb Björn Persson:
>> Reindl Harald wrote:
>>> no, in general /usr/sbin is supposed to come before /usr/bin
>>> and any software assuming the opposite has a bug
>>>
>>> Am 04.05.2014 18:11, schrieb Ankur Sinha:
/usr/bin is supposed to come before
binaries is your own, personal opinion.
no, given that /usr/sbin/iptables is clearly a administrative
command and so there is no valid reason to seek for iptables
in /usr/bin/ nor have it as override is a logical conclusion
if you want to override things /usr/local/bin and /usr/local/sbin
are you
a clearly
non-administrative command like "ls". The non-admin commands will in
most cases vastly outnumber the admin commands, so putting /usr/bin
first just makes sense from a performance standpoint.
> "Incorrect order of /usr/bin and /usr/sbin in path" is plain wrong
> and th
Reindl Harald wrote:
> no, in general /usr/sbin is supposed to come before /usr/bin
> and any software assuming the opposite has a bug
my /etc/profile contains:
# Path manipulation
if [ "$EUID" = "0" ]; then
pathmunge /usr/sbin
pathmunge /usr/local/sbin
else
pathmunge /usr/local/sbin
On Sun, 2014-05-04 at 14:19 -0400, Ray Strode wrote:
> This is probably from a recent gdm bug that was fixed upstream by this
> commit:
> https://git.gnome.org/browse/gdm/commit/?id=c9bebed8724600aef6c401f21245f7678e45
Thanks Ray. I'll wait for a gdm update and see if that fixes it.
--
Thank
On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
> however, the semantics of /usr/sbin is to contain superuser
> binaries which should not be overriden because a binary
> with the same name exists in /usr/bin
My memory is that the "s" was more for "static" not "superuser".
There's some con
On 05/05/2014 10:28 AM, Adam Jackson wrote:
On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
however, the semantics of /usr/sbin is to contain superuser
binaries which should not be overriden because a binary
with the same name exists in /usr/bin
My memory is that the "s" was more for
On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeit...@redhat.com) wrote:
> On 05/05/2014 10:28 AM, Adam Jackson wrote:
> >On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
> >
> >>however, the semantics of /usr/sbin is to contain superuser
> >>binaries which should not be overriden because a b
Once upon a time, Lennart Poettering said:
> /usr/sbin is an invention of Linux.
Hmm, I think Solaris had it, and I know DEC Unix had it.
IIRC /sbin came about for static bins, but then also to move config
binaries out of /etc. The bins not needed for early system startup
moved to /usr/sbin. I
On Mon, May 05, 2014 at 04:43:49PM +0200, Lennart Poettering wrote:
> We really should get rid of the destinction, and make all of /bin,
> /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
> about $PATH orders and namespace collisions...
This -- and the current approach of having
On Mon, May 5, 2014 at 11:00 AM, Matthew Miller
wrote:
On Mon, May 05, 2014 at 04:43:49PM +0200, Lennart Poettering wrote:
We really should get rid of the destinction, and make all of /bin,
/sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
about $PATH orders and namespac
On 05/05/2014 10:43 AM, Lennart Poettering wrote:
On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeit...@redhat.com) wrote:
On 05/05/2014 10:28 AM, Adam Jackson wrote:
On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
however, the semantics of /usr/sbin is to contain superuser
binaries wh
On Mon, 2014-05-05 at 16:43 +0200, Lennart Poettering wrote:
> On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeit...@redhat.com) wrote:
>
> > On 05/05/2014 10:28 AM, Adam Jackson wrote:
> > >On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
> > >
> > >>however, the semantics of /usr/sbin is to
On 05/05/2014 10:43 AM, Lennart Poettering wrote:
/usr/sbin is an invention of Linux.
Strange that you would claim this.
Here's a list of what's in /usr/sbin on NetBSD 1.0 (and there's no
overlap between what's in /usr/sbin and any other subdir.)
drwxr-xr-x root/wheel 0 1994-10-19
Hi,
That's my recollection as well. Heard that confusion about sbin being for
superuser before.
Jon
On 5 May 2014 15:29, "Adam Jackson" wrote:
> On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
>
> > however, the semantics of /usr/sbin is to contain superuser
> > binaries which should n
On Mon, 05.05.14 11:32, Simo Sorce (s...@redhat.com) wrote:
> On Mon, 2014-05-05 at 16:43 +0200, Lennart Poettering wrote:
> > On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeit...@redhat.com) wrote:
> >
> > > On 05/05/2014 10:28 AM, Adam Jackson wrote:
> > > >On Sun, 2014-05-04 at 18:59 +0200, Rei
On Mon, May 5, 2014 at 4:35 PM, Kaleb S. KEITHLEY wrote:
> On 05/05/2014 10:28 AM, Adam Jackson wrote:
>>
>> On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
>>
>>> however, the semantics of /usr/sbin is to contain superuser
>>> binaries which should not be overriden because a binary
>>> wi
On Mon, May 05, 2014 at 11:00:05AM -0400, Matthew Miller wrote:
> On Mon, May 05, 2014 at 04:43:49PM +0200, Lennart Poettering wrote:
> > We really should get rid of the destinction, and make all of /bin,
> > /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
> > about $PATH orders
On Mon, May 05, 2014 at 05:55:17PM +0200, Tomasz Torcz wrote:
> The full-scope cleanup looks very tempting:
> https://docs.google.com/presentation/d/1ojgzJOfWB8XaC5kqyrv4IhR9snZKBI77a02R4cj1QM8/edit#slide=id.i0
That seems to cover a lot of what I'd like to see, yeah, including moving
daemons out
On Mon, May 5, 2014 at 6:15 PM, Matthew Miller wrote:
> And calling /usr/libexec "Fedora-only" is of course kind of
> funny.
"libexec" is Fedora-only, no other major distro used it, not even LSB
allowed it.
It makes no sense to ever have that, and the rest of the world
realized that long ago.
Am 05.05.2014 21:45, schrieb Kay Sievers:
> On Mon, May 5, 2014 at 6:15 PM, Matthew Miller
> wrote:
>
>> And calling /usr/libexec "Fedora-only" is of course kind of
>> funny.
>
> "libexec" is Fedora-only, no other major distro used it, not even LSB
> allowed it.
you systemd-guys are really f
Am 05.05.2014 22:03, schrieb Kay Sievers:
> On Mon, May 5, 2014 at 9:52 PM, Reindl Harald wrote:
>> Am 05.05.2014 21:45, schrieb Kay Sievers:
>>> On Mon, May 5, 2014 at 6:15 PM, Matthew Miller
>>> wrote:
>>>
And calling /usr/libexec "Fedora-only" is of course kind of
funny.
>>>
>>> "
2014-05-05 22:03 GMT+02:00 Kay Sievers :
> On Mon, May 5, 2014 at 9:52 PM, Reindl Harald
> wrote:
> > Am 05.05.2014 21:45, schrieb Kay Sievers:
> >> On Mon, May 5, 2014 at 6:15 PM, Matthew Miller <
> mat...@fedoraproject.org> wrote:
> >>
> >>> And calling /usr/libexec "Fedora-only" is of course k
On Mon, May 5, 2014 at 9:52 PM, Reindl Harald wrote:
> Am 05.05.2014 21:45, schrieb Kay Sievers:
>> On Mon, May 5, 2014 at 6:15 PM, Matthew Miller
>> wrote:
>>
>>> And calling /usr/libexec "Fedora-only" is of course kind of
>>> funny.
>>
>> "libexec" is Fedora-only, no other major distro used it
On Mon, 2014-05-05 at 22:03 +0200, Kay Sievers wrote:
> On Mon, May 5, 2014 at 9:52 PM, Reindl Harald wrote:
> > Am 05.05.2014 21:45, schrieb Kay Sievers:
> >> On Mon, May 5, 2014 at 6:15 PM, Matthew Miller
> >> wrote:
> >>
> >>> And calling /usr/libexec "Fedora-only" is of course kind of
> >>>
Am 05.05.2014 22:19, schrieb Simo Sorce:
> On Mon, 2014-05-05 at 22:03 +0200, Kay Sievers wrote:
>> On Mon, May 5, 2014 at 9:52 PM, Reindl Harald wrote:
>>> Am 05.05.2014 21:45, schrieb Kay Sievers:
On Mon, May 5, 2014 at 6:15 PM, Matthew Miller
wrote:
> And calling /usr/libe
On Mon, May 05, 2014 at 09:45:38PM +0200, Kay Sievers wrote:
> > And calling /usr/libexec "Fedora-only" is of course kind of
> > funny.
> "libexec" is Fedora-only, no other major distro used it, not even LSB
> allowed it.
Well, Red Hat Linux, before Fedora. And I believe we got it from BSD (it
see
On Mon, 2014-05-05 at 16:19 -0400, Simo Sorce wrote:
>
> It's a practical way to keep helpers out of path and autocomplete
> without polluting /usr/lib[64] and having to deal with multilib issues,
> what's pointless about it ?
>
It causes pointless configure and Makefile complications in every
On Mon, May 05, 2014 at 04:24:03PM -0400, Matthias Clasen wrote:
> It causes pointless configure and Makefile complications in every single
> upstream project that wants to install something into that location and
> has to differentiate between Fedora (/usr/libexec) and the rest of the
> world (/us
On 05/05/2014 10:28 PM, Matthew Miller wrote:
> On Mon, May 05, 2014 at 04:24:03PM -0400, Matthias Clasen wrote:
>> It causes pointless configure and Makefile complications in every single
>> upstream project that wants to install something into that location and
>> has to differentiate between Fed
On Mon, May 05, 2014 at 10:38:10PM +0200, Kalev Lember wrote:
> On 05/05/2014 10:28 PM, Matthew Miller wrote:
> > On Mon, May 05, 2014 at 04:24:03PM -0400, Matthias Clasen wrote:
> >> It causes pointless configure and Makefile complications in every single
> >> upstream project that wants to instal
On Mon, 2014-05-05 at 16:43 +0200, Lennart Poettering wrote:
> We really should get rid of the destinction, and make all of /bin,
> /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
> about $PATH orders and namespace collisions..
Arch made exactly this change this last year. [1]
On Mon, May 05, 2014 at 09:45:38PM +0200, Kay Sievers wrote:
> On Mon, May 5, 2014 at 6:15 PM, Matthew Miller
> wrote:
>
> > And calling /usr/libexec "Fedora-only" is of course kind of
> > funny.
>
> "libexec" is Fedora-only, no other major distro used it, not even LSB
> allowed it.
>
> It mak
2014-05-06 16:06 GMT+02:00 David Cantrell :
> I think the annoying thing is if you're typing out a path that includes
> /usr/lib, you can't easily hit TAB to get in to lib. And that's worth
> fixing.
>
Oh my...
1) With the existence of /usr/lib{,64}, the additional existence of
/usr/libexec doe
On Tue, May 06, 2014 at 04:11:50PM +0200, Miloslav Trmač wrote:
>2014-05-06 16:06 GMT+02:00 David Cantrell <[1]dcantr...@redhat.com>:
>
> I think the annoying thing is if you're typing out a path that
> includes
> /usr/lib, you can't easily hit TAB to get in to lib. Â And that's
On 05/06/2014 12:25 AM, Toshio Kuratomi wrote:
>
> %{_libexecdir} and %{_libdir}/$pkg are both valid in the packaging
> guidelines.
Yep, and both valid variants differ from what other distros use. Debian
uses /usr/lib/$pkg for @libexecdir@.
>
> If upstream is using the autotools you should ju
On Tue, May 06, 2014 at 04:11:50PM +0200, Miloslav Trmač wrote:
> 2014-05-06 16:06 GMT+02:00 David Cantrell :
>
> > I think the annoying thing is if you're typing out a path that includes
> > /usr/lib, you can't easily hit TAB to get in to lib. And that's worth
> > fixing.
> >
>
> Oh my...
>
>
On 6 May 2014 10:49, Richard W.M. Jones wrote:
> On Tue, May 06, 2014 at 04:11:50PM +0200, Miloslav Trmač wrote:
> > 2014-05-06 16:06 GMT+02:00 David Cantrell :
> >
> > > I think the annoying thing is if you're typing out a path that includes
> > > /usr/lib, you can't easily hit TAB to get in to
43 matches
Mail list logo
