The directory structure for a linux system is defined by the Filesystem Hierarchy Standard.
The /usr/local directory is usually used for user installed applications that are not part of the official distribution. These generally are apps that you either installed from source or as binary tar archives. Applications installed using your distributions package management software will be installed under / and /usr.
The /var subdirectory is for variable files. Specifically, it was created for files that are modified so that it could be mounted r/w and the / and /usr be mounted read only.
/var/www is not an official standard directory of the FHS but has been used by many Linux Distributions. Other directories used on other distributions are /srv/www and /usr/share/www.
I am not familiar with Red5. If I understand you correctly it has installed demo apps under /usr/local/webapps/root/demos.
As I stated above, user installed application generally are installed under the /usr/local folder.
/var/www is where the actual HTML pages should be not applications.
The :+
is a form of parameter expansion:
${parameter:+[word]} : Use Alternative Value.
If parameter is unset or
null, null shall be substituted; otherwise, the expansion of word (or
an empty string if word is omitted) shall be substituted.
In other words, if the variable $var
is defined, echo ${var:+foo}
will print foo
and, if it is not, it will print the empty string.
The second :
is nothing special. It is the character used as a separator in the list of directories in $PATH
. So, PATH="/usr/local/bin:/usr/bin${PATH:+:${PATH}}"
is a shorthand way of writing:
if [ -z "$PATH" ]; then
PATH=/usr/local/bin:/usr/bin
else
PATH=/usr/local/bin:/usr/bin:$PATH
fi
It's just a clever trick to avoid adding an extra :
when $PATH
is not set. For example:
$ PATH="/usr/bin"
$ PATH="/new/dir:$PATH" ## Add a directory
$ echo "$PATH"
/new/dir:/usr/bin
But if PATH
is unset:
$ unset PATH
$ PATH="/new/dir:$PATH"
$ echo "$PATH"
/new/dir:
A :
by itself adds the current directory to the $PATH
. Using PATH="/new/dir${PATH:+:$PATH}"
avoids this. So sure, you can use PATH="${PATH:+${PATH}:}/usr/local/bin:/usr/bin"
if you want to, or you can use PATH="$PATH:/usr/local/bin:/usr/bin"
if you prefer. The only difference is that the former might add an extra :
, thereby adding your current directory to your $PATH
.
Best Answer
Unix systems tend to be organized with different types of files spread over different directories. For example, executables are usually in directories called
bin
(/bin
,/usr/bin
,/usr/local/bin
, …); historically,bin
stood for binary, because the executables are binaries (machine code), but there can be scripts as well. Since there are several directories that contain executables, and it's useful to add and remove directories on the fly (e.g. to test a multi-executable application, you temporarily add it to the search path for executables), there is an environment variable for that:PATH
. When you execute a program by giving its name, the shell looks it up in the directories mentioned in thePATH
variable (it's a colon-separated list of directories).The same mechanism exists for other types of files that some program is going to search for by name. Here are a few typical
PATH
-like variables (note that the example paths that I give aren't exactly what you'll find on your system, there' just there to give an idea).PATH
: executables (e.g./home/username/bin:/usr/local/bin:/usr/bin:/bin
).MANPATH
: manual pages (e.g./usr/local/man:/usr/man
).LD_LIBRARY_PATH
: native code libraries (on Linux, in addition to the value of this variable, the lookup path typically contains/usr/local/lib
,/usr/lib
,/lib
and a few others). The nameLD
comes from dynamic loader, the system component that loads libraries into dynamically linked executables.PERL5LIB
: Perl libraries (e.g./usr/local/lib/site-perl:/usr/lib/site-perl:/usr/lib/perl:/usr/share/perl
).PYTHONPATH
: Python libraries (e.g./usr/local/lib/python:/usr/lib/python:/usr/lib/python2.6
).TCLLIBPATH
: TCL libraries (e.g./usr/local/lib/tcltk:/usr/lib/tcltk
).So if your
pkg.tcl
is a standalone executable, give it execution permissions and drop it somewhere in$PATH
. If it's a TCL library loaded by a TCL program, drop it somewhere in$TCLLIBPATH
.