Diskussion:Bash/Debug: Unterschied zwischen den Versionen
K Textersetzung - „ “ durch „ “ |
K Textersetzung - „wikitable“ durch „table table-striped table-hover“ |
||
| Zeile 4: | Zeile 4: | ||
This is the <code>commented-script1.sh</code> script ran in debug mode. Note again that the added comments are not visible in the output of the script. | This is the <code>commented-script1.sh</code> script ran in debug mode. Note again that the added comments are not visible in the output of the script. | ||
{| class=" | {| class="table table-striped table-hover" | ||
| | | | ||
|} | |} | ||
| Zeile 11: | Zeile 11: | ||
== Debugging on part(s) of the script == | == Debugging on part(s) of the script == | ||
Using the '''set''' Bash built-in you can run in normal mode those portions of the script of which you are sure they are without fault, and display debugging information only for troublesome zones. Say we are not sure what the '''w''' command will do in the example <code>commented-script1.sh</code>, then we could enclose it in the script like this: | Using the '''set''' Bash built-in you can run in normal mode those portions of the script of which you are sure they are without fault, and display debugging information only for troublesome zones. Say we are not sure what the '''w''' command will do in the example <code>commented-script1.sh</code>, then we could enclose it in the script like this: | ||
{| class=" | {| class="table table-striped table-hover" | ||
| | | | ||
|} | |} | ||
Output then looks like this: | Output then looks like this: | ||
{| class=" | {| class="table table-striped table-hover" | ||
| | | | ||
|} | |} | ||
| Zeile 23: | Zeile 23: | ||
'''Table 2-1. Overview of set debugging options''' | '''Table 2-1. Overview of set debugging options''' | ||
{| class=" | {| class="table table-striped table-hover" | ||
!Short notation | !Short notation | ||
!Long notation | !Long notation | ||
| Zeile 43: | Zeile 43: | ||
In the example below, we demonstrate these options on the command line: | In the example below, we demonstrate these options on the command line: | ||
{| class=" | {| class="table table-striped table-hover" | ||
| | | | ||
|} | |} | ||
| Zeile 51: | Zeile 51: | ||
Once you found the buggy part of your script, you can add '''echo''' statements before each command of which you are unsure, so that you will see exactly where and why things don't work. In the example <code>commented-script1.sh</code> script, it could be done like this, still assuming that the displaying of users gives us problems: | Once you found the buggy part of your script, you can add '''echo''' statements before each command of which you are unsure, so that you will see exactly where and why things don't work. In the example <code>commented-script1.sh</code> script, it could be done like this, still assuming that the displaying of users gives us problems: | ||
{| class=" | {| class="table table-striped table-hover" | ||
| | | | ||
|} | |} | ||
In more advanced scripts, the '''echo''' can be inserted to display the content of variables at different stages in the script, so that flaws can be detected: | In more advanced scripts, the '''echo''' can be inserted to display the content of variables at different stages in the script, so that flaws can be detected: | ||
{| class=" | {| class="table table-striped table-hover" | ||
| | | | ||
|} | |} | ||
Aktuelle Version vom 29. Juli 2026, 10:49 Uhr
TMP
Debugging on the entire script
When things don't go according to plan, you need to determine what exactly causes the script to fail. Bash provides extensive debugging features. The most common is to start up the subshell with the -x option, which will run the entire script in debug mode. Traces of each command plus its arguments are printed to standard output after the commands have been expanded but before they are executed.
This is the commented-script1.sh script ran in debug mode. Note again that the added comments are not visible in the output of the script.
There is now a full-fledged debugger for Bash, available at SourceForge. These debugging features are available in most modern versions of Bash, starting from 3.x.
Debugging on part(s) of the script
Using the set Bash built-in you can run in normal mode those portions of the script of which you are sure they are without fault, and display debugging information only for troublesome zones. Say we are not sure what the w command will do in the example commented-script1.sh, then we could enclose it in the script like this:
Output then looks like this:
You can switch debugging mode on and off as many times as you want within the same script.
The table below gives an overview of other useful Bash options:
Table 2-1. Overview of set debugging options
| Short notation | Long notation | Result |
|---|---|---|
| set -f | set -o noglob | Disable file name generation using metacharacters (globbing). |
| set -v | set -o verbose | Prints shell input lines as they are read. |
| set -x | set -o xtrace | Print command traces before executing command. |
The dash is used to activate a shell option and a plus to deactivate it. Don't let this confuse you!
In the example below, we demonstrate these options on the command line:
Alternatively, these modes can be specified in the script itself, by adding the desired options to the first line shell declaration. Options can be combined, as is usually the case with UNIX commands:
#!/bin/bash -xv
Once you found the buggy part of your script, you can add echo statements before each command of which you are unsure, so that you will see exactly where and why things don't work. In the example commented-script1.sh script, it could be done like this, still assuming that the displaying of users gives us problems:
In more advanced scripts, the echo can be inserted to display the content of variables at different stages in the script, so that flaws can be detected: