Differences

This shows you the differences between two versions of the page.

Link to this comparison view

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 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>​
  
  • scripting/debuggingtips.1438920884.txt
  • Last modified: 2015/08/07 04:14
  • by bill_thomson