Troubleshooting bash scripts.
This document (3286517) is provided subject to the disclaimer at the end of this document.
Environment
SUSE Linux Enterprise Server 10
SUSE Linux Enterprise Desktop 10
SUSE Linux Enterprise Desktop 10
Situation
A common way to automate tasks quickly and simply on an Operating System (OS) is to use a script. Scripts do not require any manual compilation and use the commands which are familiar to the computer operator. As a result they can be written quickly and with less formal training than some other types of programs. Debugging scripts is fairly simple but there are some features built into 'bash' which make this even faster and simpler.
Resolution
The Bourne Again SHell (bash) is the default for most implementations of Linux and many other Unix-based operating systems. One of the parameters bash accepts when loading is'-x'. When using this parameter bash returns a large amount of information about every command it receives including values of variables, values involved in a comparison, commands run, alias resolution to commands, etc. Being able to enable this and disable it during runtime can minimize the extra information being sent to the screen while providing all that is necessary to get to the bottom of a problem.
Loading `bash -x` loads bash with it set to 'Print commands and their arguments as they are executed.' per the bash man page. An example of bash running normally and with -x follow. In each example the `ls` command is run.
Normal bash:
user@host:/var> ls
adm c1-install.log cache games lib lock log mail opt run spool tmp X11R6 yp
2007-06-20 22:51:58 Jobs:0 Err:0
user@host:/var>
bash -x
user@host:/var> ls
+ /bin/ls -N --color=tty -T 0
adm c1-install.log cache games lib lock log mail opt run spool tmp X11R6 yp
2007-06-20 22:52:59 Jobs:0 Err:0
user@host:/var>
As you can see immediately after the command is a line starting with '+' which indicates what was really run. It turns out that 'ls' is an alias for '/bin/ls -N --color=tty -T 0' which adds some color to the output (not visible here) for readability purposes. Running scripts with 'bash -x' increases the amount of output by several times (if not hundreds or thousands of times). Note that often when a script is called it loads a new version of bash which probably does not have '-x' after it. Either modify the script's first line to add the -x after'#!/bin/bash' or else call the script with bash directly along with the '-x' as follows:
user@host:~/Desktop> bash -x ./test.sh
+ ls
meeting.jnlp test.sh workorder8.log
++ date +%s
+ DATESECSVAR=1182401830
+ echo 1182401830
1182401830
2007-06-20 22:57:10 Jobs:0 Err:0
user@host:~/Desktop>
This script had three lines. The first did a simple listing ('ls'), the second set a variable to the output of 'date +%s' (notice the two plus signs... this indicates that there was some kind of embedded command or function there) and finally the last command echoed the variable's output to the screen. While the script contained a 'shebang' line (#!/bin/bash) that did not include the '-x', because the script was called with 'bash -x ./test.sh' directly the first line was overridden and a new shell ready for debugging was used.
Enabling and disabling this feature on the fly can also be done with a simple 'set' command.
Enable: `set -x`
Disable: `set +x`
Go ahead and give that a try. After enabling your commands should look a bit different because of all the debugging information. Once you've disabled things again it will be back to normal. These commands can also be embedded in a script around a problem area to get extra output about that section alone.
The last thing to note is all output from '-x' goes, by default, to STDERR (standard error). As a result if you have more than you can read during processing you can easily redirect all that output to a file while still being able to see the other normal output you expect. Do this simply by appending'2>/path/to/your/desired/file.log' to your command. For example with the previous example:
user@host:~/Desktop> bash -x ./test.sh 2>/tmp/shellOutputFile.log
meeting.jnlp test.sh workorder8.log
1182402059
2007-06-20 23:00:59 Jobs:0 Err:0
user@host:~/Desktop>
After running the command as indicated above I have just the '-x' output in /tmp/shellOutputFile.log.
Loading `bash -x` loads bash with it set to 'Print commands and their arguments as they are executed.' per the bash man page. An example of bash running normally and with -x follow. In each example the `ls` command is run.
Normal bash:
user@host:/var> ls
adm c1-install.log cache games lib lock log mail opt run spool tmp X11R6 yp
2007-06-20 22:51:58 Jobs:0 Err:0
user@host:/var>
bash -x
user@host:/var> ls
+ /bin/ls -N --color=tty -T 0
adm c1-install.log cache games lib lock log mail opt run spool tmp X11R6 yp
2007-06-20 22:52:59 Jobs:0 Err:0
user@host:/var>
As you can see immediately after the command is a line starting with '+' which indicates what was really run. It turns out that 'ls' is an alias for '/bin/ls -N --color=tty -T 0' which adds some color to the output (not visible here) for readability purposes. Running scripts with 'bash -x' increases the amount of output by several times (if not hundreds or thousands of times). Note that often when a script is called it loads a new version of bash which probably does not have '-x' after it. Either modify the script's first line to add the -x after'#!/bin/bash' or else call the script with bash directly along with the '-x' as follows:
user@host:~/Desktop> bash -x ./test.sh
+ ls
meeting.jnlp test.sh workorder8.log
++ date +%s
+ DATESECSVAR=1182401830
+ echo 1182401830
1182401830
2007-06-20 22:57:10 Jobs:0 Err:0
user@host:~/Desktop>
This script had three lines. The first did a simple listing ('ls'), the second set a variable to the output of 'date +%s' (notice the two plus signs... this indicates that there was some kind of embedded command or function there) and finally the last command echoed the variable's output to the screen. While the script contained a 'shebang' line (#!/bin/bash) that did not include the '-x', because the script was called with 'bash -x ./test.sh' directly the first line was overridden and a new shell ready for debugging was used.
Enabling and disabling this feature on the fly can also be done with a simple 'set' command.
Enable: `set -x`
Disable: `set +x`
Go ahead and give that a try. After enabling your commands should look a bit different because of all the debugging information. Once you've disabled things again it will be back to normal. These commands can also be embedded in a script around a problem area to get extra output about that section alone.
The last thing to note is all output from '-x' goes, by default, to STDERR (standard error). As a result if you have more than you can read during processing you can easily redirect all that output to a file while still being able to see the other normal output you expect. Do this simply by appending'2>/path/to/your/desired/file.log' to your command. For example with the previous example:
user@host:~/Desktop> bash -x ./test.sh 2>/tmp/shellOutputFile.log
meeting.jnlp test.sh workorder8.log
1182402059
2007-06-20 23:00:59 Jobs:0 Err:0
user@host:~/Desktop>
After running the command as indicated above I have just the '-x' output in /tmp/shellOutputFile.log.
Disclaimer
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:3286517
- Creation Date: 20-Jun-2007
- Modified Date:24-Feb-2021
-
- SUSE Linux Enterprise Desktop
- SUSE Linux Enterprise Server
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com
