WiredRevolution.com » environment variable

Find the PID of the current Bash script

Ryan — Sun, 09 Jan 2011 17:18:51 +0000

In many cases you will need to determine the PID of a current Bash script or shell. Bash stores a specific variable that allows you to view the process ID of the current shell “$$‘.

You can echo the $$ to print the current PID.
$ echo $$23490

View process environment details with proc

Ryan — Wed, 10 Dec 2008 12:42:25 +0000

The process environment consists of all the individual environment variables which are passed on to the program by the shell when the program is launched. This environment can be read and changed by the program during its execution, and can affect how a program is linked or how it executes. For all these reasons it may be important at times to see exactly what the environment contains. The proc filesystem provides the interface to make this happen.

The proc pseudo-file system is used as an interface to kernel data structures. It is commonly mounted at /proc and most of the files inside are read-only. Within proc there exists a subdirectory for every running process on the system identified by its process ID (PID).

Inside each process directory is an environ file which contains the current environment for that process.

/proc//environ

This file is limited at this point in time to 4096 characters. Therefore if you have a process with an unusually large environment the data beyond this limit will be truncated.

The environment variable entries are separated by null characters ‘\0‘, which makes it difficult to view the file. The best way to get around this is with the tr command which will replace the the null characters with newline characters ‘\n‘.

$ cat /proc/12345/environ | tr "\000" "\n"

Command substitution in BASH

Ryan — Fri, 07 Nov 2008 13:42:59 +0000

BASH has the ability to execute a command string and replace that string with the output of the command. Or to say it another way, the output of a command will replace the command itself.

There are 2 ways to accomplish this.

The first is to surround the command with backticks or blockquotes.
`command`

You can also substitute with dollar symbol and parenthesis.
$(command)

The following will do a direct substitution of the current username on the command line.

$ echo /home/$(whoami)

/home/ryan

Another great use is the ability to assign a command to an environment variable.

$ MYDATE=`date`

or using the other format

$ MYDATE=$(date)

How to correctly use LD_LIBRARY_PATH

Ryan — Wed, 22 Oct 2008 12:32:13 +0000

The LD_LIBRARY_PATH environment variable contains a colon separated list of paths that the linker uses to resolve library dependencies of ELF executables at run-time. These paths will be given priority over the standard library paths /lib and /usr/lib. The standard paths will still be searched, but only after the list of paths in LD_LIBRARY_PATH has been exhausted.

The best way to use LD_LIBRARY_PATH is to set it on the command line or script immediately before executing the program. This way you can keep the new LD_LIBRARY_PATH isolated from the rest of your system.

$ export LD_LIBRARY_PATH="/list/of/library/paths:/another/path"
$ ./program

In general it is not a good practice to have LD_LIBRARY_PATH permanently set in your environment. This could lead to unintended side effects as programs can link to unintended libraries producing strange results or unexpectedly crashing. There is also the possibility introducing potential security threats.

All those warnings aside, if you are using BASH you can set it permanently by placing a line similar to this in your .bashrc in your home directory.

export LIBRARY_PATH="/list/of/library/paths:/another/path"

A common case for setting LD_LIBRARY_PATH is when you have an application that requires dynamic libraries which were not installed in the standard library locations.

You can check if the linker can locate all the required libraries by running the ldd command.

$ ldd ~/myprogram

	librt.so.1 => /lib/librt.so.1 (0x00002b4eca08e000)
	libc.so.6 => /lib/libc.so.6 (0x00002b4eca49f000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00002b4eca7df000)
	/lib64/ld-linux-x86-64.so.2 (0x00002b4ec9e72000)
	libmylib.so.1 => not found

The linker cannot find libmylib.so.1.

Let’s assume this library exists here “~/myprogdir/lib/libmylib.so.1″. We have to set LD_LIBRARY_PATH to include this path for the application to successfully run.

$ export LD_LIBRARY_PATH="~/myprogdir/lib/:$LD_LIBRARY_PATH"
$ ldd ~/myprogram

	librt.so.1 => /lib/librt.so.1 (0x00002b4eca08e000)
	libc.so.6 => /lib/libc.so.6 (0x00002b4eca49f000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00002b4eca7df000)
	/lib64/ld-linux-x86-64.so.2 (0x00002b4ec9e72000)
	libmylib.so.1 => ~/myprogdir/lib/libmylib.so.1 (0x00002b4eca9fa000)

The linker has now found all the required libraries.

Customize the BASH PS1 command prompt

Ryan — Sun, 19 Oct 2008 14:45:22 +0000

The PS1 environment controls the appearance of the BASH command line prompt. There are a variety of default prompts but they usually include username, hostname, and working directory. You can easily customize your prompt to display information important to you as well as add color and style formatting.

Here we can see the default prompt is “username@hostname working_directory $”.

ryan@workstation ~ $

You can echo the PS1 environment variable and see the character codes which are used to create the output.

ryan@workstation ~ $ echo $PS1

\u@\h \w \$

Here is a list of all the special character codes you can use to build your PS1 command prompt.

Special Character Codes

\a – an ASCII bell character (07)
\d – the date in “Weekday Month Date” format (e.g., “Tue May 26″)
\D{format} – the format is passed to strftime(3) and the result is inserted into the prompt string; an empty format results in a locale-specific time representation. The braces are required
\e – an ASCII escape character (033)
\h – the hostname up to the first `.’
\H – the hostname
\j – the number of jobs currently managed by the shell
\l – the basename of the shell’s terminal device name
\n – newline
\r – carriage return
\s – the name of the shell, the basename of $0 (the portion following the final slash)
\t – the current time in 24-hour HH:MM:SS format
\T – the current time in 12-hour HH:MM:SS format
\@ – the current time in 12-hour am/pm format
\A – the current time in 24-hour HH:MM format
\u – the username of the current user
\v – the version of bash (e.g., 2.00)
\V – the release of bash, version + patchelvel (e.g., 2.00.0)
\w – the current working directory
\W – the basename of the current working directory
\! – the history number of this command
\# – the command number of this command
\$ – if the effective UID is 0, a #, otherwise a $
\nnn – the character corresponding to the octal number nnn
\\ – a backslash
\[ - begin a sequence of non-printing characters, which could be used to embed a terminal control sequence into the prompt
\] – end a sequence of non-printing characters

Lets try a simple change. Make sure you use double quotes so the escape characters get passed on to the variable and not expanded in the shell.

ryan@workstation ~ $ PS1="My Prompt: $ "

My Prompt: $

As you can see the prompt will immediately change to reflect the changes.

We can add the date to the prompt.

ryan@workstation ~ $ PS1="\d \u@\h \w \$ "

Sun Oct 19 ryan@workstation ~ $

Now lets add some color to our original prompt.

ryan@workstation ~ $ PS1="\[\e[1;32m\]\u@\h\[\e[1;34m\] \w \$\[\e[0m\] "

Let go over this in detail.

A style block will display all text that follows with the style it defines. The block contains 3 elements.

Lets look at the first block.
“\[\e[1;32m\]”

“\[" - begin a sequence of non-printing characters
"\e[1;32m" - the semicolon separated list of style/color codes (in this case bold;green)
"\]” – end a sequence of non-printing characters

The first block will display the following username@hostname text in BOLD green.
“\[\e[1;32m\]\u@\h\[\e[1;34m\] \w \$\[\e[0m\] ”

The second block will display the following working_directory text in BOLD blue.
“\[\e[1;32m\]\u@\h\[\e[1;34m\] \w \$\[\e[0m\] ”

The final block resets the colors.
“\[\e[1;32m\]\u@\h\[\e[1;34m\] \w \$\[\e[0m\] ”

Here is a rundown of all the color and style codes.

Color and Style Codes

Style
0 – default
1 – bold
4 – underline
7 – inverse
9 – strikeout

Foreground Colors
30 – foreground Black
31 – foreground Red
32 – foreground Green
33 – foreground Yellow
34 – foreground Blue
35 – foreground Magenta
36 – foreground Cyan
37 – foreground White

Background Colors
40 – background Black
41 – background Red
42 – background Green
43 – background Yellow
44 – background Blue
45 – background Magenta
46 – background Cyan
47 – background White

You can combine multiple codes to create the exact style you want.
“\[\e[1;4;36;47m\]”
This style block defines bold and underlined cyan text with a white background.

To make these changes permanent place your new prompt string like the one below in your ~/.bashrc file in your home directory.

PS1="\[\e[1;32m\]\u@\h\[\e[1;34m\] \w \$ \[\e[0m\]"

This file is sourced every time you start a new interactive shell.

Select threading implementation using LD_ASSUME_KERNEL

Ryan — Mon, 13 Oct 2008 12:37:09 +0000

For backwards compatibility, many Linux distributions support both the older LinuxThreads implementation as well as the newer Native POSIX Thread Library (NPTL). By setting the LD_ASSUME_KERNEL environment variable you can tell the dynamic linker to assume that it is running on top of a particular kernel version. This will override the dynamic linker’s default choice of threading implementation (usually NPTL) and force the use of the older LinuxThreads implementation at run-time.

Many 32-bit systems have 3 separate glibc versions which have support for a minimum OS Application Binary Interface (ABI), designated by a kernel version and offer support for a particular thread implementation.

/lib/tls/libc.so.6

minimum ABI = 2.4.20
Native POSIX Thread Library (NPTL)

/lib/i686/libc.so.6

minimum ABI = 2.4.1
standard LinuxThreads

/lib/libc.so.6

minimum ABI = 2.2.5
early LinuxThreads code which had fixed size threads

It is worth noting that 64-bit systems do not support the older 2.2.5 LinuxThreads implementation.

You can run the following commands to see what thread implementations are supported by each separate glibc library.

$ /lib/tls/libc.so.6 | grep [T|t]hreads

	Native POSIX Threads Library by Ulrich Drepper

$ /lib/i686/libc.so.6 | grep [T|t]hreads

	linuxthreads-0.10 by Xavier Leroy

$ /lib/libc.so.6 | grep [T|t]hreads

	linuxthreads-0.10 by Xavier Leroy

A shared library can tell the dynamic linker which minimum OS ABI version is needed for it to successfully run. At run-time the linker will start at the most recent library path and walk backwards in this order: /lib/tls, /lib/i686, /lib. It will either link to the first library it finds or fail and terminate the program if the minimum ABI is reached before it finds a library.

Setting LD_ASSUME_KERNEL below the minimum threshold ABI version of any dynamic library will cause the linker to skip that library and try to find an older implementation

Set the environment variable by assigning it to a specific ABI/kernel version.

$ export LD_ASSUME_KERNEL=X.Y.Z

You must be careful not to set the the ABI below 2.2.5 in your environment as all programs which require dynamic linking will probably fail to run. Luckily you are still be able to unset or change it back.

It is useless to set LD_ASSUME_KERNEL for most programs as they will run correctly no matter what underlying implementation is used since the API is the same. However there are some programs that may depend on some non-conformant behavior requiring LinuxThreads, which will fail with NPTL.