We typically struggle with debugging when we deal with longer and more complicated scripts, and we rarely need to set these options and leave them set while we run multiple scripts. Now surely you are thinking that sounds fine, but we seldom need help debugging mistakes made in one-liners at the command line or in short scripts like these. Using u option running your script from the command line So these are real time savers when we make mistakes that do not result in actual errors from the Bash interpreter’s point of view. Using the -u switch,we immediately get a notification that our variable j is not bound to a value. This is not an error that will halt execution of the script, so we’re left to simply wonder without being given any clues. We only get one value printed per line instead of two. Looking this next example, we also get no indication of an error from the interpreter. Sometimes we look right at a mistake like this and it doesn’t look wrong until we get a clue and think, “Why is $path evaluated to an empty string?” $path is an empty string because we accidentally put a dollar sign in front of “path” in our read statement. Running it again using the -x option clearly shows us that the left side of our comparison is an empty string. It does not give us any indication of why or clues to mistakes made. In the example above we run the addpath script normally and it simply does not modify our PATH. Using x option when running your Bash script This is the -u switch, and just like -x and -v it can also be used on the command line, as we see in the following example: There is another useful switch we can use to help us find variables referenced without having any value set. If you are not sure which options are enabled, you can examine the $- variable to see the current state of all the variables. The Bash options for debugging are turned off by default, but once they are turned on by using the set command, they stay on until explicitly turned off. In more complicated examples this can be quite useful. We also see on the line beginning with a plus sign what the statement looks like again after the substitution, which shows us the actual values compared inside the if statement. Notice how using -x and -v options together allows us to see the original if statement before the $USER variable is expanded, thanks to the -v option. Setting x and v options at the command line This can be applied to a script by invoking Bash with the -x switch. The first option to mention is probably the most useful too – the xtrace option. So there are a few built-in debugging options we can use to see what is going wrong. When writing shell scripts, the programming logic tends to be shorter and is often contained within a single file. They may be implemented as a short function that shows the timing, line number and such, or something like this: $ echo "function_name(): value of \\$var is $" How to use Bash xtrace option Assertions can pinpoint even the subtlest of bugs. ![]() These are basically a ways of explicitly asserting conditions or the state of things at a point in time. There are techniques used in traditional programming environments that can be useful with complex Bash scripts, such as using assertions. Some programming languages come with companion debugging environments, like gcc and gdb that let you step through code, set breakpoints, examine the state of everything at those points in the execution and more – but there’s generally less need for a heavy handed approach like that with shell scripts since the code is simply interpreted instead of being compiled into binaries. Simply having syntax highlighting will allow you to catch mistakes as you write the code, saving you the time-consuming task of tracking down mistakes later. ![]() It’s no different when writing Bash scripts. Programmers have traditionally taken advantage of tools like debuggers and syntax highlighting in editors to assist them. $ – requires given linux commands to be executed as a regular non-privileged userĭebugging code can be tricky, even if the mistakes are simple and obvious. # – requires given linux commands to be executed with root privileges either directly as a root user or by use of sudo command Requirements, Conventions or Software Version Used ![]() ![]() – Brian Kernighan, “Unix for Beginners” (1979) Software Requirements and Conventions Used Software Requirements and Linux Command Line Conventions Category The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |