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:16]
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 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.1438920985.txt
  • Last modified: 2015/08/07 04:16
  • by bill_thomson