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> | ||