Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
scripting:debuggingtips [2015/08/07 04:14] bill_thomson |
scripting:debuggingtips [2017/06/07 02:42] (current) fgrose [Making xtrace more useful] set variables with descriptive words |
||
|---|---|---|---|
| Line 25: | Line 25: | ||
| ===== Use a good editor ===== | ===== Use a good editor ===== | ||
| - | Your choice of editor is a matter of personal preference, but one **with Bash syntax highlighting** is highly recommended! Syntax highlighting helps you see (you guessed it) syntax errors, such as unclosed quotes and braces, typos, etc. | + | Your choice of editor is a matter of personal preference, but one with **Bash syntax highlighting** is highly recommended! Syntax highlighting helps you see (you guessed it) syntax errors, such as unclosed quotes and braces, typos, etc. |
| From my personal experience, I can suggest ''vim'' or ''GNU emacs''. | From my personal experience, I can suggest ''vim'' or ''GNU emacs''. | ||
| Line 130: | Line 130: | ||
| That helps a lot when the script is long, or when the main script sources many other files. | That helps a lot when the script is long, or when the main script sources many other files. | ||
| + | === Set flag variables with descriptive words === | ||
| + | If you test variables that flag the state of options, such as with ''%%if [[ -n $option ]];%%'', consider using descriptive words rather than short codes, such as 0, 1, Y, N, because xtrace will show ''%%[[ -n word ]]%%'' rather than ''%%[[ -n 1 ]]%%'' when the option is set. | ||
| ===== Debugging commands depending on a set variable ===== | ===== Debugging commands depending on a set variable ===== | ||
| Line 203: | Line 204: | ||
| * did you close your ''{'' with a ''}''? | * did you close your ''{'' with a ''}''? | ||
| * did you close your ''('' with a '')''? | * did you close your ''('' with a '')''? | ||
| - | * ... | + | |
| **__Note:__** It seems that here-documents (tested on versions ''1.14.7'', ''2.05b'', ''3.1.17'' and ''4.0'') are correctly terminated when there is an EOF before the end-of-here-document tag (see [[syntax:redirection | redirection]]). The reason is unknown, but it seems to be deliberate. Bash 4.0 added an extra message for this: ''warning: here-document at line <N> delimited by end-of-file (wanted `<MARKER>')'' | **__Note:__** It seems that here-documents (tested on versions ''1.14.7'', ''2.05b'', ''3.1.17'' and ''4.0'') are correctly terminated when there is an EOF before the end-of-here-document tag (see [[syntax:redirection | redirection]]). The reason is unknown, but it seems to be deliberate. Bash 4.0 added an extra message for this: ''warning: here-document at line <N> delimited by end-of-file (wanted `<MARKER>')'' | ||
| Line 224: | Line 225: | ||
| * single-quote pairs (also ''<nowiki>$'string'</nowiki>''!) | * single-quote pairs (also ''<nowiki>$'string'</nowiki>''!) | ||
| * missing a closing ''}'' with [[syntax:pe | parameter expansion syntax]] | * missing a closing ''}'' with [[syntax:pe | parameter expansion syntax]] | ||
| - | * ... | + | |
| Line 259: | Line 260: | ||
| </code> | </code> | ||
| - | then you most likely have an alias defined with the same name as the function (here: ''foo''). Alias expansion happens before the real language interpretion, thus the alias is expanded and makes your function definition invalid. | + | you most likely have an alias defined with the same name as the function (here: ''foo''). Alias expansion happens before the real language interpretion, thus the alias is expanded and makes your function definition invalid. |
| ===== The CRLF issue ===== | ===== The CRLF issue ===== | ||
| Line 270: | Line 271: | ||
| * UNIX(r) uses: ''\n'' (ASCII ''LF'' #10) | * UNIX(r) uses: ''\n'' (ASCII ''LF'' #10) | ||
| - | Keep in mind your script file **is a plain text file**, and the ''CR'' character means nothing special to UNIX(r) - it is treated like any other character. If it's printed to your terminal, a carriage return will effectively place the cursor at the beginning of the //current// line. This can cause much confusion and many headaches, since lines containing CRs are not what they appear to be when printed. In summary, CRs are a pain. | + | Keep in mind your script is a **plain text file**, and the ''CR'' character means nothing special to UNIX(r) - it is treated like any other character. If it's printed to your terminal, a carriage return will effectively place the cursor at the beginning of the //current// line. This can cause much confusion and many headaches, since lines containing CRs are not what they appear to be when printed. In summary, CRs are a pain. |
| ==== How did a CR end up in my file? ==== | ==== How did a CR end up in my file? ==== | ||
| Line 277: | Line 278: | ||
| * a DOS/Windows text editor | * a DOS/Windows text editor | ||
| * a UNIX(r) text editor that is "too smart" when determining the file content type (and thinks "//it's a DOS text file//") | * a UNIX(r) text editor that is "too smart" when determining the file content type (and thinks "//it's a DOS text file//") | ||
| - | * a direct copy&paste from certain webpages (some pastebins are known for this) | + | * a direct copy and paste from certain webpages (some pastebins are known for this) |
| Line 306: | Line 307: | ||
| <note warning> | <note warning> | ||
| - | It's easy tp imagine the ''^M'' is bad in other places too. So if you get weird and illogical messages from your script, chances are good ''^M'' is envolved. Find and eliminate it! | + | It's easy to imagine the ''^M'' is bad in other places too. If you get weird and illogical messages from your script, rule out the possibility that''^M'' is involved. Find and eliminate it! |
| </note> | </note> | ||