PATH in Debian?

AndeAnderson · 10-26-2005, 07:47 AM

I keep running into the same error with Debian while trying to use some of the basic Linux commands.

# cupsys restart
-bash: cupsys: command not found

Yet, when I type in:

# /etc/init.d/cupsys restart

it works.

Why is the PATH so restricted in Debian? How can I change or add to the PATH for Debian?

I read the Debian Reference Doc and found:

`PATH' is set by the following configuration files in this order:

/etc/login.defs - before the shell sets PATH
/etc/profile (may call /etc/bash.bashrc)
~/.bash_profile (may call ~/.bashrc)

The files listed here do not exist on my Debian Sarge stable system. So, where does Debian really keep the PATH configuration?

Command Line inputs are also somewhat confusing in Linux. Sometimes you type the command then the object, man adduser (run the man), and other times you have to type it backwards with the object then the command, cupsys -restart (the man run).

The only way to know which input to use is trial and error. This really should be a standardized item. One way or the other.

farslayer · 10-26-2005, 08:43 AM

the path is indeed stored in /etc/profile in debian stable

/etc is not part of the path and shouldn't be part of the path. the PATH only includes locations where you would find binaries or systembinaries that would be executed by the privileged or unprivileged users. cupsys is a startup script for a service and not an binary you would normally run all the time. it's been this way on every distro I have ever worked in..

Quote:

user@debstablel:~$ more /etc/profile
# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

if [ "`id -u`" -eq 0 ]; then # uid 0 is the root user
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"
fi

echo $PATH to view your current PATH settings

in the case of:
man adduser : man is the command and adduser is the object you want a man page on... you are not executing adduser here.

adduser newuser : here you are executing addusr as the command and telling it to add the user newusr

cupsys -restart : cupsys is the executable or script and -restart is what action you want it to perform

The executable or script is ALWAYS first, the variable, or options come after.. I really don't see how this is confusing, but then again I started using pc's back in the DOS days..

hope that helps to clear things up.

AndeAnderson · 10-26-2005, 09:21 AM

Thanks farslayer, for the info.

I just wasn't thinking in the proper direction. For some reason I did not consider cupsys to be the executable. I thought that commands like -restart, -stop, -start were the system executables, just like halt or logout. I see now, from your explanation, they are just the options for the executable.

I double checked and found profile as a file. With no extension on the file name. such as .conf, I had been looking for a directory named /etc/profile with a .conf file in it.

Just another little quirk in Linux I will have to learn. Files do not require extensions to identify what they are. They can be text, scripts, configuration, executables, etc... and it is up to me to figure out what they are.

Another question about the PATH for executables.

Why aren't the executables added to the PATH or a directory, which is in the PATH, when an application is installed? I understand the need to protect system executable files, but to require the user to have to figure out which directory a script is located in before they can use seems like a very frustrating exercise, especially for new users, like me.

Why not have a directory named /usr/scripts or /usr/common for these executables and have that listed in the PATH?

Again, Thanks.

dastrike · 10-26-2005, 09:47 AM

Quote:

Originally posted by AndeAnderson
Just another little quirk in Linux I will have to learn. Files do not require extensions to identify what they are. They can be text, scripts, configuration, executables, etc... and it is up to me to figure out what they are.

You can use the command file to investigate what type of file it is. E.g.

$ file /etc/init.d/cupsys
/etc/init.d/cupsys: Bourne shell script text executable

And typically if a file is marked executable it is executable (it is possible to have files incorrectly marked as executable though).

Quote:

Another question about the PATH for executables.

Why aren't the executables added to the PATH or a directory, which is in the PATH, when an application is installed? I understand the need to protect system executable files, but to require the user to have to figure out which directory a script is located in before they can use seems like a very frustrating exercise, especially for new users, like me.
Why not have a directory named /usr/scripts or /usr/common for these executables and have that listed in the PATH?

Executables are put into the PATH whenever suitable.
Executables suitable for exectution by regular users are placed in /bin, /usr/bin, /usr/local/bin, /usr/X11R6/bin, which are all in the PATH of a regular user.
Executables that only root should normally execute are placed in /sbin, /usr/sbin, /usr/local/sbin which are all in the PATH of the root user in addition to the above mentioned ones
Then there are special cases just like the scripts used to control services that are placed in /etc/init.d or other similar. One good reason to have them separate is that some of the scripts names are the same as the executable of which they use. E.g. the /etc/init.d/ntpdate uses the /usr/sbin/ntpdate executable. It would be ambiguous in a fashion and/or confusing to have both them in the PATH at the same time, and prefixing the service control scripts with something wouldn't really accomplish that much since as they are placed in a separate directory they are essetially effectively already prefixed, albeit with a full directory path /etc/init.d/

Ygrex · 10-26-2005, 09:51 AM

About file types there is a command 'file'. It can help you to
determine a file type.
About path to executables there no frustrating at all. Why should be
directies like /etc/scripts ? If you want your script could be run then
simply place it to e.g. /usr/local/bin.