Where's ifconfig?

[daniel]

okay, you have sbin in your path 

[jwt873]

Here's a tip I learned a while back to see if something is installed...

When searching for a specific utility program (from the command line), you can use the 'which' command.

[jim@localhost ~]$ which ifconfig
/sbin/ifconfig
[jim@localhost ~]$ which which
/usr/bin/which
[jim@localhost ~]$

[YouCanToo]

okay, you have sbin in your path 

Why is it in some paths and not in everyone's path?

[daniel]

okay, you have sbin in your path 

Why is it in some paths and not in everyone's path?

I've no idea, why it is, sorry...

[AS]

okay, you have sbin in your path 

Why is it in some paths and not in everyone's path?

I have already seen this: different PCLinuxOS flavors have different PATH setup. From one side it's understandable, because something like /usr/lib/kde4/libexec is meaningful to KDE only, from another side the lack of /sbin as appear to be the case in this thread, is questionable.

[rudge12000@localhost ~]$ echo $PATH
/bin:/usr/bin:/usr/local/bin:/usr/games:/usr/lib/qt4/bin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/home/rudge12000/bin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin
[rudge12000@localhost ~]$

Also, the duplicates entries like in Rudge's $PATH, IMHO aren't entirely correct ...

AS

[Bald Brick]

okay, you have sbin in your path  

Why is it in some paths and not in everyone's path?

I have already seen this: different PCLinuxOS flavors have different PATH setup. From one side it's understandable, because something like /usr/lib/kde4/libexec is meaningful to KDE only, from another side the lack of /sbin as appear to be the case in this thread, is questionable.

When I started using Linux many years ago the sbin directories were missing from ordinary users' paths in most distros I tried. This made sense as the executables in /sbin and /usr/sbin are there for administrative tasks and mainly intended to be run by root.

On the other hand I don't remember seeing a KDE version of PCLinuxOS where they wouldn't be found in my ordinary user's default path. This also makes sense as some of the programs in the sbin directories actually can be run by ordinary users. I don't think either solution is wrong.

[rudge12000@localhost ~]$ echo $PATH
/bin:/usr/bin:/usr/local/bin:/usr/games:/usr/lib/qt4/bin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/home/rudge12000/bin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin
[rudge12000@localhost ~]$

Also, the duplicates entries like in Rudge's $PATH, IMHO aren't entirely correct ...

AS

Any program can add to the existing path and most scripts don't check for existing entries before they add their own. Creating a new default path won't help unless you can also find and edit all the scrips that are messing with your old one. But a few duplicate entries won't matter.

For instance the last part of Rudge's path (the final /usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin) might have been added by /etc/profile.d/kde4env.sh.

[Just17]

Check the group membership of the user .......  they also affect what commands are available to users .....  when comparing two installs. For instance I also have access to such commands as fdisk from a user prompt, while others don't.

[AS]

okay, you have sbin in your path  

Why is it in some paths and not in everyone's path?

I have already seen this: different PCLinuxOS flavors have different PATH setup. From one side it's understandable, because something like /usr/lib/kde4/libexec is meaningful to KDE only, from another side the lack of /sbin as appear to be the case in this thread, is questionable.

When I started using Linux many years ago the sbin directories were missing from ordinary users' paths in most distros I tried. This made sense as the executables in /sbin and /usr/sbin are there for administrative tasks and mainly intended to be run by root.

On the other hand I don't remember seeing a KDE version of PCLinuxOS where they wouldn't be found in my ordinary user's default path. This also makes sense as some of the programs in the sbin directories actually can be run by ordinary users. I don't think either solution is wrong.

That was exactly my point, I have used the terms "is questionable" meaning that "can be discussed"  ... (non native English here),
I can add that several other distros are currently using /sbin and /usr/sbin in user's PATH.

[rudge12000@localhost ~]$ echo $PATH
/bin:/usr/bin:/usr/local/bin:/usr/games:/usr/lib/qt4/bin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/home/rudge12000/bin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin
[rudge12000@localhost ~]$

Also, the duplicates entries like in Rudge's $PATH, IMHO aren't entirely correct ...

AS

Any program can add to the existing path and most scripts don't check for existing entries before they add their own. Creating a new default path won't help unless you can also find and edit all the scrips that are messing with your old one. But a few duplicate entries won't matter.

... a few duplicate can affect a process performance when you run a script like:

Code: [Select]

for i in *
do
      [example executable in /home/rudge1200/bin]
done
when you run a script like the above, every time the example executable is called, the shell will search the command in each directory listed on the PATH until will find the right directory, every time the command is executed.

For instance the last part of Rudge's path (the final /usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin) might have been added by /etc/profile.d/kde4env.sh.

Beside the performance issue, which may be ignored, PATH define also a precedence between commands, the first example that come to my mind is shutdown that is present in /sbin and in /usr/bin and are different executables. 

AS

[Vorteggs]

Here's a tip I learned a while back to see if something is installed...

When searching for a specific utility program (from the command line), you can use the 'which' command.

[jim@localhost ~]$ which ifconfig
/sbin/ifconfig
[jim@localhost ~]$ which which
/usr/bin/which
[jim@localhost ~]$

The OP simply had to type his question in Terminal :

[Vorteks@thenudiebar ~]$ whereis ifconfig
ifconfig: /sbin/ifconfig /usr/share/man/man8/ifconfig.8.bz2
[Vorteks@thenudiebar ~]$

[Bald Brick]

okay, you have sbin in your path  

Why is it in some paths and not in everyone's path?

I have already seen this: different PCLinuxOS flavors have different PATH setup. From one side it's understandable, because something like /usr/lib/kde4/libexec is meaningful to KDE only, from another side the lack of /sbin as appear to be the case in this thread, is questionable.

When I started using Linux many years ago the sbin directories were missing from ordinary users' paths in most distros I tried. This made sense as the executables in /sbin and /usr/sbin are there for administrative tasks and mainly intended to be run by root.

On the other hand I don't remember seeing a KDE version of PCLinuxOS where they wouldn't be found in my ordinary user's default path. This also makes sense as some of the programs in the sbin directories actually can be run by ordinary users. I don't think either solution is wrong.

That was exactly my point, I have used the terms "is questionable" meaning that "can be discussed"  ... (non native English here),
I can add that several other distros are currently using /sbin and /usr/sbin in user's PATH.

[rudge12000@localhost ~]$ echo $PATH
/bin:/usr/bin:/usr/local/bin:/usr/games:/usr/lib/qt4/bin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/home/rudge12000/bin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin
[rudge12000@localhost ~]$

Also, the duplicates entries like in Rudge's $PATH, IMHO aren't entirely correct ...

AS

Any program can add to the existing path and most scripts don't check for existing entries before they add their own. Creating a new default path won't help unless you can also find and edit all the scrips that are messing with your old one. But a few duplicate entries won't matter.

... a few duplicate can affect a process performance when you run a script like:

Code: [Select]

for i in *
do
      [example executable in /home/rudge1200/bin]
done
when you run a script like the above, every time the example executable is called, the shell will search the command in each directory listed on the PATH until will find the right directory, every time the command is executed.

I see you point. The shell will stop searching once it's found the right executable but if there are duplicates of other directories it may repeatedly search for it several times in /bin and /usr/bin until it possibly finds it in /usr/sbin.

For instance the last part of Rudge's path (the final /usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin) might have been added by /etc/profile.d/kde4env.sh.

Beside the performance issue, which may be ignored, PATH define also a precedence between commands, the first example that come to my mind is shutdown that is present in /sbin and in /usr/bin and are different executables.  

AS

I suppose that is why some scripts append their entries to the PATH variable while other scripts prepend them. If you wish to change the search order of the most important directories your additions should come before the old path; if you wish to minimize the disturbance caused by your additions, add them to the end of the path.

Nevertheless the strangest thing about Rudges PATH variable is that it seems to contain the path from /etc/profile.d/kde4env.sh -- not once, but twice. And this in spite of the fact that he doesn't run KDE but LXDE.

It's also interesting that /etc/profile.d/kde4env.sh appears to have been run first before ~/.bash_profile was read, and then once more afterwards. (How do I know this? It's normally ~/.bash_profile that adds the bin in the user's home directory to the PATH variable.)

[demilord]

Same here working as user