Lâmôlabs

Background

From time to time it’s useful if you can turn up the debugging messages that come from Bash, when working out either interactive or shell script problems. Here are 2 methods that can help in getting down to the details.

Solution

There are essentially 2 methods.

Method #1: -x method

When writing a shell script you’ll sometimes want to turn on line by line debugging. There’s basically 2 ways to to this.

Before we get started, suppose we have this sample script, myscript.bash:

1
2
3
4

#!/bin/bash
 
echo "hi"
echo "bye"

First you can run your script like so:

1
2
3
4
5

% bash -x myscript.bash
+ echo hi
hi
+ echo bye
bye

As an alternative you can add the following line, set -x to the top of our shell script to enable debugging as well:

1
2
3
4
5

#!/bin/bash
 
set -x
echo "hi"
echo "bye"

1
2
3
4
5

% ./myscript.bash
+ echo hi
hi
+ echo bye
bye

Method #2: env SHELLOPTS=xtrace …

This approach sets the env. variable SHELLOPTS=xtrace which has the same effect as using bash -x.

For example:

1
2
3
4
5

% env SHELLOPTS=xtrace ./myscript.bash 
+ echo hi
hi
+ echo bye
bye

You can also use this technique to debug your bash environment (think .bashrc and .bash_profile) like so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

% env SHELLOPTS=xtrace bash
...
...
+++++ line='complete -f -X
'\''!*.@(zip|[ejw]ar|exe|pk3|wsz|zargo|xpi|sxw|o[tx]t|od[fgpst]|epub|apk)'\''
unzip zipinfo'
+++++ line=' unzip zipinfo'
+++++ list=("${list[@]}" $line)
+++++ read line
+++++ '[' 'complete -f -X '\''*.Z'\'' compress znew' '!=' 'complete -f
-X '\''*.Z'\'' compress znew' ']'
+++++ line='complete -f -X '\''*.Z'\'' compress znew'
+++++ line='complete -f -X '\''*.Z'\'' compress znew'
+++++ line=' compress znew'
+++++ list=("${list[@]}" $line)
+++++ read line
+++++ '[' ' zcmp, zdiff, z*grep, zless, zmore intentionally not here,
see Debian: #455510' '!=' '# zcmp, zdiff, z*grep, zless, zmore
intentionally not here, see Debian: #455510' ']'
...
...

Here you can see every command getting executed from the system and user’s .bashrc and .bash_profile as bash starts up.

NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.

Background

While answering questions on the stackexchage website Unix & Linux I saw the following question which was about something I’d encountered, but until today never knew how to accomplish, so I’m posting it here for my own reference in the future.

The question?

How do you get the exit status ( $? ) from the command haconf -makerw in place of grep? i.e. what need to add in to my syntax in order to understand if haconf -makerw succeeded?

1
2

    haconf -makerw | grep -iq "Cluster already writable"
        # echo $? ( will print the exe status from haconf -makerw  )

Solution

There are 3 ways of doing this. However your current setup should work. The reason here being that the grep won’t match anything if the command fails, so grep will return with status 1 (unless the program always shows that text no matter what).

Pipefail

The first way is to set the pipefail option. This is the simplest and what it does is basically set the exit status $? to the exit code of the last program to exit non-zero (or zero if all exited successfully).

1
2
3
4
5

# false | true; echo $?
0
# set -o pipefail
# false | true; echo $?
1

$PIPESTATUS

Bash also has a variable called $PIPESTATUS which contains the exit status of all the programs in the last command.

…. Continue reading → [one-liner]: How do you capture the status of a command ($?) in Bash, when run through a pipe? »»

Background

I recently came across this question on the Stackexchange site Unix & Linux. This question was interesting in the sense that it covered much of the I/O redirection facilities that are available in the Bash Shell, so for posterity sake I’m adding my answer to this question here on my blog.

Solution

• a number 1 = standard out (i.e. STDOUT)
• a number 2 = standard error (i.e. STDERR)
• if a number isn’t explicitly given, then number 1 is assumed by the shell (bash)

First let’s tackle the function of these. For reference see the Advanced Bash-Scripting Guide.

Functions

Portability to non-bash, tcsh, mksh, etc.

I’ve not dealt much with other shells outside of csh and tcsh. My experience with those 2 compared to bash’s redirection operators, is that bash is superior in that regard. See the tcsh man page for more details.

Of the commands asked about in the Unix & Linux question, none are directly supported by csh or tcsh. You’d have to use different syntaxes to construct similar functions.

References

• Advanced Bash-Scripting Guide
• tcsh man page
• stackexchange unix & linux question regarding shell redirections

NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.