{"id":187,"date":"2018-10-19T00:00:00","date_gmt":"2018-10-18T16:00:00","guid":{"rendered":"https:\/\/yeslq.com\/201810187.html"},"modified":"2019-05-07T10:43:34","modified_gmt":"2019-05-07T02:43:34","slug":"the-linux-command-line-stay-out-of","status":"publish","type":"post","link":"https:\/\/yeslq.com\/?p=187","title":{"rendered":"The Linux Command Line—Stay Out Of Trouble"},"content":{"rendered":"

\nThe Linux Command Line <\/a><\/i>by William Shotts<\/span><\/h1>\n
\n
<\/span><\/div>\n
\n<\/p>\n
\nNow that our scripts are getting a little more complicated, I want to point out some common mistakes that you might run into. To do this, create the following script called trouble.bash. Be sure to enter it exactly as written.<\/div>\n
\n
#!\/bin\/bash\n\nnumber=1\n\nif [ $number = \"1\" ]; then\n    echo \"Number equals 1\"\nelse\n    echo \"Number does not equal 1\"\nfi\n       \n<\/pre>\n<\/div>\n
\nWhen you run this script, it should output the line “Number equals 1” because, well, number equals 1. If you don’t get the expected output, check your typing; you made a mistake.<\/div>\n
\nEmpty Variables<\/h2>\n
\nEdit the script to change line 3 from:<\/div>\n
\n
number=1\n       \n<\/pre>\n<\/div>\n
\nto:<\/div>\n
\n
number=\n       \n<\/pre>\n<\/div>\n
\nand run the script again. This time you should get the following:<\/div>\n
\n[me@linuxbox me]$ .\/trouble.bash
\/trouble.bash: [: =: unary operator expected.
Number does not equal 1<\/div>\n
\nAs you can see, bash displayed an error message when we ran the script. You probably think that by removing the “1” on line 3 it created a syntax error on line 3, but it didn’t. Let’s look at the error message again:<\/div>\n
\n.\/trouble.bash: [: =: unary operator expected<\/div>\n
\nWe can see that .\/trouble.bash is reporting the error and the error has to do with “[“. Remember that “[” is an abbreviation for the test shell builtin. From this we can determine that the error is occurring on line 5 not line 3.<\/div>\n
\nFirst, let me say there is nothing wrong with line 3. number= is perfectly good syntax. You will sometimes want to set a variable’s value to nothing. You can confirm the validity of this by trying it on the command line:<\/div>\n
\n[me@linuxbox me]$ number=
[me@linuxbox me]$<\/div>\n
\nSee, no error message. So what’s wrong with line 5? It worked before.<\/div>\n
\nTo understand this error, we have to see what the shell sees. Remember that the shell spends a lot of its life expanding text. In line 5, the shell expands the value of number where it sees $number. In our first try (when number=1), the shell substituted 1 for $number like so:<\/div>\n
\n
if [ 1 = \"1\" ]; then\n       \n<\/pre>\n<\/div>\n
\nHowever, when we set number to nothing (number=), the shell saw this after the expansion:<\/div>\n
\n
if [ = \"1\" ]; then\n       \n<\/pre>\n<\/div>\n
\nwhich is an error. It also explains the rest of the error message we received. The “=” is a binary operator; that is, it expects two items to operate upon – one on each side. What the shell is trying to tell us is that there is only one item and there should be a unary operator (like “!”) that only operates on a single item.<\/div>\n
\nTo fix this problem, change line 5 to read:<\/div>\n
\n
if [ \"$number\" = \"1\" ]; then\n       \n<\/pre>\n<\/div>\n
\nNow when the shell performs the expansion it will see:<\/div>\n
\n
if [ \"\" = \"1\" ]; then\n       \n<\/pre>\n<\/div>\n
\nwhich correctly expresses our intent.<\/div>\n
\nThis brings up an important thing to remember when you are writing your scripts. Consider what happens if a variable is set to equal nothing.<\/div>\n
\nMissing Quotes<\/h2>\n
\nEdit line 6 to remove the trailing quote from the end of the line:<\/div>\n
\n
   echo \"Number equals 1\n       \n<\/pre>\n<\/div>\n
\nand run the script again. You should get this:<\/div>\n
\n[me@linuxbox me]$ .\/trouble.bash
.\/trouble.bash: line 8: unexpected EOF while looking for matching “
.\/trouble.bash: line 10 syntax error: unexpected end of file<\/div>\n
\nHere we have another case of a mistake in one line causing a problem later in the script. What happens is the shell keeps looking for the closing quotation mark to tell it where the end of the string is, but runs into the end of the file before it finds it.<\/div>\n
\nThese errors can be a real pain to find in a long script. This is one reason you should test your scripts frequently when you are writing them so there is less new code to test. I also find that text editors with syntax highlighting make these kinds of bugs easier to find.<\/div>\n
\nIsolating Problems<\/h2>\n
\nFinding bugs in your programs can sometimes be very difficult and frustrating. Here are a couple of techniques that you will find useful:<\/div>\n
\nIsolate blocks of code by “commenting them out.”<\/b> This trick involves putting comment characters at the beginning of lines of code to stop the shell from reading them. Frequently, you will do this to a block of code to see if a particular problem goes away. By doing this, you can isolate which part of a program is causing (or not causing) a problem.<\/div>\n
\nFor example, when we were looking for our missing quotation we could have done this:<\/div>\n
\n
#!\/bin\/bash\n\nnumber=1\n\nif [ $number = \"1\" ]; then\n    echo \"Number equals 1\n#else\n#   echo \"Number does not equal 1\"\nfi\n       \n<\/pre>\n<\/div>\n
\nBy commenting out the else clause and running the script, we could show that the problem was not in the else clause even though the error message suggested that it was.<\/div>\n
\nUse echo commands to verify your assumptions.<\/b> As you gain experience tracking down bugs, you will discover that bugs are often not where you first expect to find them. A common problem will be that you will make a false assumption about the performance of your program. You will see a problem develop at a certain point in your program and assume that the problem is there. This is often incorrect, as we have seen. To combat this, you should place echocommands in your code while you are debugging, to produce messages that confirm the program is doing what is expected. There are two kinds of messages that you should insert.<\/div>\n
\nThe first type simply announces that you have reached a certain point in the program. We saw this in our earlier discussion on stubbing. It is useful to know that program flow is happening the way we expect.<\/div>\n
\nThe second type displays the value of a variable (or variables) used in a calculation or test. You will often find that a portion of your program will fail because something that you assumed was correct earlier in your program is, in fact, incorrect and is causing your program to fail later on.<\/div>\n
\nWatching Your Script Run<\/h2>\n
\nIt is possible to have bash show you what it is doing when you run your script. To do this, add a “-x” to the first line of your script, like this:<\/div>\n
\n
#!\/bin\/bash -x\n       \n<\/pre>\n<\/div>\n
\nNow, when you run your script, bash will display each line (with expansions performed) as it executes it. This technique is called tracing<\/i>. Here is what it looks like:<\/div>\n
\n[me@linuxbox me]$ .\/trouble.bash
+ number=1
+ ‘[‘ 1 = 1 ‘]’
+ echo ‘Number equals 1’
Number equals 1<\/div>\n
\nAlternately, you can use the set command within your script to turn tracing on and off. Use set -x to turn tracing on and set +x to turn tracing off. For example.:<\/div>\n
\n
#!\/bin\/bash\n\nnumber=1\n\nset -x\nif [ $number = \"1\" ]; then\n    echo \"Number equals 1\"\nelse\n    echo \"Number does not equal 1\"\nfi\nset +x\n       <\/pre>\n<\/div>\n
<\/span><\/div>\n","protected":false},"excerpt":{"rendered":"
The Linux Command Line by William Shotts Now that  … \u9605\u8bfb\u66f4\u591a<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[51,52,53],"class_list":["post-187","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-linux","tag-shell","tag-the-linux-command-line"],"_links":{"self":[{"href":"https:\/\/yeslq.com\/index.php?rest_route=\/wp\/v2\/posts\/187","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/yeslq.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/yeslq.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/yeslq.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/yeslq.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=187"}],"version-history":[{"count":1,"href":"https:\/\/yeslq.com\/index.php?rest_route=\/wp\/v2\/posts\/187\/revisions"}],"predecessor-version":[{"id":317,"href":"https:\/\/yeslq.com\/index.php?rest_route=\/wp\/v2\/posts\/187\/revisions\/317"}],"wp:attachment":[{"href":"https:\/\/yeslq.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=187"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/yeslq.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=187"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/yeslq.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=187"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}