Bash игнорировать ошибки

Bash, or the Bourne-Again Shell, is a powerful command-line interface (CLI) that is commonly used in Linux and Unix systems. When working with Bash, it is important to understand how to handle errors that may occur during the execution of commands. In this article, we will discuss various ways to understand and ignore errors in Bash. Bash scripting is a powerful tool for automating and simplifying various tasks in Linux and Unix systems. However, errors can occur during the execution of commands and can cause scripts to fail. In this article, we will explore the various ways to understand and handle errors in Bash. We will look at ways to check the exit status code and error messages of commands, as well as techniques for ignoring errors when necessary. By understanding and properly handling errors, you can ensure that your Bash scripts run smoothly and achieve the desired outcome.

Step-by-step approach for understanding and ignoring errors in Bash:

Step 1: Understand how errors are generated in Bash.

• When a command is executed, it returns an exit status code.
• A successful command will have an exit status of 0, while a failed command will have a non-zero exit status.
• Error messages are generated when a command returns a non-zero exit status code.

Step 2: Check the exit status code of a command.

• To check the exit status code of a command, you can use the $? variable, which holds the exit status of the last executed command.
• For example, after executing the command ls non_existent_directory, you can check the exit status code by running echo $? The output
• will be non-zero (e.g., 2) indicating that the command failed.

Step 3: Check the error message of a command.

• To check the error message of a command, you can redirect the standard error output (stderr) to a file or to the standard output (stdout) using the 2> operator.
• For example, you can redirect the stderr of the command ls non_existent_directory to a file by running ls non_existent_directory 2> error.log. Then you can view the error message by running cat error.log.

Step 4: Use the set -e command.

• The set -e command causes the script to exit immediately if any command exits with a non-zero status. This can be useful for detecting and handling errors early on in a script.
• For example, if you run set -e followed by ls non_existent_directory, the script will exit immediately with an error message. 

Step 5: Ignore errors when necessary.

• To ignore errors, you can use the command || true construct. This construct allows you to execute a command, and if it returns a non-zero exit status, the command following the || operator (in this case, true) will be executed instead.
• For example, you can run rm non_existent_file || true to remove a file that does not exist without exiting with an error.
• Another way to ignore errors is to use the command 2> /dev/null construct, which redirects the standard error output (stderr) of a command to the null device, effectively ignoring any error messages.
• Additionally, you can use the command 2>&1 >/dev/null construct to ignore both standard error and standard output.
• You can also use the command || : construct which allows you to execute a command and if it returns a non-zero exit status, the command following the || operator (in this case, 🙂 will be executed instead. The: command is a no-op command that does nothing, effectively ignoring the error.

Practical Explanation for Understanding Errors

First, let’s examine how errors are generated in Bash. When a command is executed, it returns an exit status code. This code indicates whether the command was successful (exit status 0) or not (non-zero exit status). For example, the following command attempts to list the files in a directory that does not exist:

$ ls non_existent_directory
ls: cannot access 'non_existent_directory': No such file or directory

As you can see, the command generated an error message and returned a non-zero exit status code. To check the exit status code of a command, you can use the $? variable, which holds the exit status of the last executed command.

$ echo $?
2

In addition to the exit status code, you can also check the standard error output (stderr) of a command to understand errors. This can be done by redirecting the stderr to a file or to the standard output (stdout) using the 2> operator.

For example, the following script will redirect the stderr of a command to a file:

$ ls non_existent_directory 2> error.log
$ cat error.log
ls: cannot access 'non_existent_directory': No such file or directory

You can also redirect the stderr to the stdout using the 2>&1 operator, which allows you to see the error message along with the standard output of the command.

$ ls non_existent_directory 2>&1
ls: cannot access 'non_existent_directory': No such file or directory

Another useful tool for understanding errors is the set -e command, which causes the script to exit immediately if any command exits with a non-zero status. This can be useful for detecting and handling errors early on in a script.

$ set -e
$ ls non_existent_directory
# as soon as you hit enter this will exit shell and will close the terminal.

After this command script will exit from the shell if the exit code is nonzero.

Practical Explanation for Ignoring Errors

While it is important to handle errors in Bash scripts, there may be certain situations where you want to ignore errors and continue running the script. In this section, we will discuss different methods for ignoring errors in Bash and provide examples of how to implement them.

Heredoc

Heredoc is a feature in Bash that allows you to specify a string or command without having to escape special characters. This can be useful when you want to ignore errors that may occur while executing a command. The following example demonstrates how to use Heredoc to ignore errors.

#!/bin/bash

# Example of ignoring errors using Heredoc

# The `command` will fail but it will not stop execution
cat <<EOF | while read line; do
  echo $line
done
command that will fail
EOF

# Rest of the script

In this example, the command that is inside the Heredoc will fail, but the script will not stop execution. This is because the output of the command is piped to the while loop, which reads the output and ignores the error.

Pipefail

The pipe fails option in Bash can be used to change the behavior of pipelines so that the exit status of the pipeline is the value of the last (rightmost) command to exit with a non-zero status or zero if all commands exit successfully. This can be useful when you want to ignore errors that may occur while executing multiple commands in a pipeline. The following example demonstrates how to use the pipe fail option to ignore errors.

#!/bin/bash

# Example of ignoring errors using pipefail

# The `command1` will fail but it will not stop execution
set -o pipefail
command1 | command2

# Rest of the script

In this example, command1 will fail, but command2 will continue to execute, and the script will not stop execution.

Undefined Variables

By default, Bash will stop the execution of a script if an undefined variable is used. However, you can use the -u option to ignore this behavior and continue running the script even if an undefined variable is used. The following example demonstrates how to ignore undefined variables.

#!/bin/bash

# Example of ignoring undefined variables

set +u

echo $undefined_variable

# Rest of the script

In this example, the script will not stop execution when an undefined variable is used.

Compiling and Interpreting

When compiling or interpreting a script, errors may occur. However, these errors can be ignored by using the -f option when running the script. The following example demonstrates how to ignore errors when compiling or interpreting a script.

#!/bin/bash

# Example of ignoring errors when compiling or interpreting

bash -f script.sh

# Rest of the script

In this example, the script will continue to run even if there are errors during the compilation or interpretation process.

Traps

A trap is a way to execute a command or a set of commands when a specific signal is received by the script. This can be useful when you want to ignore errors and run a cleanup command instead. The following example demonstrates how to use a trap to ignore errors.

#!/bin/bash

# Example of ignoring errors using a trap

# Set a trap to run the cleanup function when an error occurs
trap cleanup ERR

# Function to run when an error occurs
cleanup() {
  echo "Cleaning up before exiting..."
}

# Command that will cause an error
command_that_will_fail

# Rest of the script

In this example, when the command_that_will_fail causes an error, the script will execute the cleanup function instead of stopping execution. This allows you to perform any necessary cleanup before exiting the script.

Examples of Bash for Error Handling:

Example 1: Error Handling Using a Conditional Condition

One way to handle errors in Bash is to use a conditional statement. The following example demonstrates how to check for a specific error and handle it accordingly.

#!/bin/bash

# Example of error handling using a conditional condition

file=example.txt

if [ ! -f $file ]; then
  echo "Error: $file does not exist"
  exit 1
fi

# Rest of the script

In this example, we check if the file “example.txt” exists using the -f option of the [ command. If the file does not exist, the script will print an error message and exit with a status code of 1. This allows the script to continue running if the file exists and exit if it does not.

Example 2: Error Handling Using the Exit Status Code

Another way to handle errors in Bash is to check the exit status code of a command. Every command in Bash returns an exit status code when it completes, with a code of 0 indicating success and any other code indicating an error. The following example demonstrates how to check the exit status code of a command and handle it accordingly.

#!/bin/bash

# Example of error handling using the exit status code

command1

if [ $? -ne 0 ]; then
  echo "Error: command1 failed"
  exit 1
fi

# Rest of the script

In this example, the script runs the command “command1” and then checks the exit status code using the special variable $?. If the exit status code is not 0, the script will print an error message and exit with a status code of 1.

Example 3: Stop the Execution on the First Error

When running a script, it can be useful to stop the execution on the first error that occurs. This can be achieved by using the set -e command, which tells Bash to exit the script if any command exits with a non-zero status code.

#!/bin/bash

# Stop execution on the first error

set -e

command1
command2
command3

# Rest of the script

In this example, if any of the commands “command1”, “command2” or “command3” fail, the script will exit immediately.

Example 4: Stop the Execution for Uninitialized Variable

Another way to stop execution on error is if an uninitialized variable is used during script execution. This can be achieved by using the set -u command, which tells Bash to exit the script if any uninitialized variable is used.

#!/bin/bash

# Stop execution for uninitialized variable

set -u

echo $uninitialized_variable

# Rest of the script

In this example, if the uninitialized_variable is not defined, the script will exit immediately.

Conclusion

In conclusion, understanding and ignoring errors in Bash is an important aspect of working with the command-line interface. By checking the exit status code of a command, its associated error message, and redirecting the stderr to a file or the stdout, you can understand what went wrong. And by using the command || true, command 2> /dev/null, command 2>&1 >/dev/null, and command || : constructs, you can ignore errors when necessary. It’s always a good practice to test these constructs in a testing environment before using them in production.

You can put 2>/dev/null behind a command to suppress errors:

ls /home/cas/thisfolderdoesntexist -> error

ls /home/cas/thisfolderdoesntexist 2>/dev/null -> no output because error is suppressed.

You can also put 2>/dev/null behind a script to run the complete script with errors suppressed:

./script.sh 2>/dev/null

What your doing is redirecting (>) errors (2) to /dev/null. Every piece of data (in this case the output of your command(s)/script) that is redirected to /dev/null will be completely ignored. See it as a trash can for data.

---

Edit:
2>/dev/null suppresses the output of the command, not the complete pipe. In the example that you gave, you’re supressing errors from the awk command. If the error is comming from the ls command, do the following (this will suppress errors from the ls command):

ls /bootpool 2>/dev/null | grep boot | awk 'NR==1{print $1}'

If the error is comming from the grep command:

ls /bootpool | grep boot 2>/dev/null | awk 'NR==1{print $1}'

I think you get it now.

A good thing to remember:

1 = stdout = normal output of a command

2 = stderr = error output of a command

0 = stdin = input to a command (this isn’t usefull for redirecting, more for logging)

---

I also improved your script (using shellcheck, you can install it or use their online tool link):

#!/bin/sh
boot=$(find /bootpool/*boot* 2>/dev/null | sed "s|/.*/||")
data=$(find /datapool/*boot* 2>/dev/null | sed "s|/.*/||")
echo "boot"
if [ "$boot" = "boot" ] 
then
        echo "boot"
        pass=$(grep rootpw /bootpool/boot/loader.conf | grep -o '".*"' | sed 's|"||g' | awk 'BEGIN { ORS = " " } { print }')

elif [ "$data" = "boot" ]
then
        pass=$(grep rootpw /datapool/boot/loader.conf | grep -o '".*"' | sed 's|"||g' | awk 'BEGIN { ORS = " " } { print }')

else
        echo "Couldn't find boot in bootpool nor datapool"
        exit
fi

if [ "$pass" = edjos ]
then
        echo "You are at default password. kindly change the password"
        oldpass=$(grep root /etc/master.passwd | awk 'NR==1 { print $1 }' | cut -d ':' -f 2 | sed 's/$/%/g')
        passwd
        newpass=$(grep root /etc/master.passwd | awk 'NR==1 { print $1 }' | cut -d ':' -f 2 | sed 's/$/%/g')
        if [ "$newpass" != "$oldpass" ]
        then              
                if [ "$boot" = "boot" ]
                then 
                        sed -i.bak '/mfsbsd.rootpw/s/edjos//' /bootpool/boot/loader.conf
                        sed -i.bak '/mfsbsd.rootpwhash/d' /bootpool/boot/loader.conf
                        echo "mfsbsd.rootpwhash="$newpass""  >> /bootpool/boot/loader.conf
                        echo "Great! password updated successfully"

                elif [ "$data" = "boot" ]
                then
                        sed -i.bak '/mfsbsd.rootpw/s/edjos//' /datapool/boot/loader.conf
                        sed -i.bak '/mfsbsd.rootpwhash/d' /datapool/boot/loader.conf
                        echo "mfsbsd.rootpwhash="$newpass""  >> /datapool/boot/loader.conf
                        echo "Great! password updated successfully"
                fi
        fi
else
        echo "Great! you are having authorised password"
fi

1. You were using == but /bin/sh doesn’t make use of that. Only =. When you use /bin/bash, == will actually become usefull. But as you don’t, you need to use =.
2. I changed the way you set the boot and data variables. The way you did it was inefficient.
3. When both $boot and $data are empty, the script will catch it instead of letting you continue. This is handy because in your second if statement, when $oldpass and $newpass aren’t equal, it depends on either $boot or $data to contain «boot». But what if they don’t? That’s what the else is for in the first if-statement.
4. Putting "" around variables. echo $var -> echo "$var"

Ignoring errors in a section of a Bash script

For simonw/museums#32 I wanted to have certain lines in my Bash script ignore any errors: lines that used sqlite-utils to add columns and configure FTS, but that might fail with an error if the column already existed or FTS had already been configured.

This tip on StackOverflow lead me to the following recipe:

#!/bin/bash
set -euo pipefail

yaml-to-sqlite browse.db museums museums.yaml --pk=id
python annotate_nominatum.py browse.db
python annotate_timestamps.py
# Ignore errors in following block until set -e:
set +e
sqlite-utils add-column browse.db museums country 2>/dev/null
sqlite3 browse.db < set-country.sql
sqlite-utils disable-fts browse.db museums 2>/dev/null
sqlite-utils enable-fts browse.db museums 
  name description country osm_city 
  --tokenize porter --create-triggers 2>/dev/null
set -e

Everything between the set +e and the set -e lines can now error without the Bash script itself failing.

The failing lines were still showing a bunch of Python tracebacks. I fixed that by redirecting their standard error output to /dev/null like this:

sqlite-utils disable-fts browse.db museums 2>/dev/null