Differences

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

Link to this comparison view

Both sides previous revision Previous revision
scripting:obsolete [2015/08/07 03:22]
bill_thomson
scripting:obsolete [2015/08/07 03:24] (current)
bill_thomson
Line 33: Line 33:
 |''​typeset'' ​ |''​declare'',​ ''​local'',​ ''​export'',​ ''​readonly'' ​ |This is closely related to the above, and should often be used together. ''​typeset''​ exists primarily for ''​ksh''​ compatibility,​ but is marked as "​deprecated"​ in Bash (though I don't entirely agree with this). This makes some sense, because future compatibility can't be guaranteed, and any compatibility at all, requires understanding the non-POSIX features of other shells and their differences. Using ''​declare''​ instead of ''​typeset''​ emphasizes your intention to be "​Bash-only",​ and definitely breaks everywhere else (except possibly zsh if you're lucky). The issue is further complicated by Dash and the [[http://​www.debian.org/​doc/​debian-policy/​ch-files.html#​s-scripts | Debian policy]] requirement for a ''​local''​ builtin, which is itself not entirely compatible with Bash and other shells. | |''​typeset'' ​ |''​declare'',​ ''​local'',​ ''​export'',​ ''​readonly'' ​ |This is closely related to the above, and should often be used together. ''​typeset''​ exists primarily for ''​ksh''​ compatibility,​ but is marked as "​deprecated"​ in Bash (though I don't entirely agree with this). This makes some sense, because future compatibility can't be guaranteed, and any compatibility at all, requires understanding the non-POSIX features of other shells and their differences. Using ''​declare''​ instead of ''​typeset''​ emphasizes your intention to be "​Bash-only",​ and definitely breaks everywhere else (except possibly zsh if you're lucky). The issue is further complicated by Dash and the [[http://​www.debian.org/​doc/​debian-policy/​ch-files.html#​s-scripts | Debian policy]] requirement for a ''​local''​ builtin, which is itself not entirely compatible with Bash and other shells. |
 |''​let '​EXPR'​ '' ​ |''<​nowiki>​((EXPR))</​nowiki>''​ or ''​[\ <​nowiki>​$((EXPR))</​nowiki>​\ -ne\ 0 ]'' ​ |''​let''​ is the "​simple command"​ variant of arithmetic evaluation command, which takes regular arguments. Both ''​let''​ and ''<​nowiki>​((expr))</​nowiki>''​ were present in ksh88, and everything that supports one should support the other. Neither are POSIX. The compound variant is preferable because it doesn'​t take regular arguments for [[syntax:​expansion:​wordsplit | wordsplitting]] and [[syntax:​expansion:​globs | globbing]], which makes it safer and clearer. It is also usually faster, especially in Bash, where compound commands are typically significantly faster. Some of the (few) reasons for using ''​let''​ are detailed on the [[commands:​builtin:​let | let]] page. See [[syntax:​ccmd:​arithmetic_eval | arithmetic evaluation compound command]] | |''​let '​EXPR'​ '' ​ |''<​nowiki>​((EXPR))</​nowiki>''​ or ''​[\ <​nowiki>​$((EXPR))</​nowiki>​\ -ne\ 0 ]'' ​ |''​let''​ is the "​simple command"​ variant of arithmetic evaluation command, which takes regular arguments. Both ''​let''​ and ''<​nowiki>​((expr))</​nowiki>''​ were present in ksh88, and everything that supports one should support the other. Neither are POSIX. The compound variant is preferable because it doesn'​t take regular arguments for [[syntax:​expansion:​wordsplit | wordsplitting]] and [[syntax:​expansion:​globs | globbing]], which makes it safer and clearer. It is also usually faster, especially in Bash, where compound commands are typically significantly faster. Some of the (few) reasons for using ''​let''​ are detailed on the [[commands:​builtin:​let | let]] page. See [[syntax:​ccmd:​arithmetic_eval | arithmetic evaluation compound command]] |
-|''​eval'' ​ |Depends. Often code can be restructured to use better alternatives. ​ |''​eval''​ is thrown in here for good measure, as sadly it is so often misused that any use of ''​eval''​ (even the rare clever one) is immediately dismissed as wrong by experts, and among the most immediate solutions abused by beginners. In reality, there are correct ways to use ''​eval'',​ and even cases in which it's necessary, even in sophisticated shells like Bash and Ksh. ''​eval''​ is unusual in that it is less frequently appropriate in more feature-rich shells than in more minimal shells like Dash, where it is used to compensate for more limitations. If you find yourself needing ''​eval''​ too frequently, it might be a sign that you're either better off using a different language entirely, or trying to borrow an idiom from some other paradigm that isn't well suited to the shell language. By the same token, there are some cases in which working too hard to avoid ''​eval''​ ends up adding a lot of complexity and sacrificing all portability. ​Basically, don't substitute a clever ''​eval''​ for something ​else that's a bit "too clever",​ just to avoid the ''​eval'', ​while still taking ​reasonable measures to avoid it where it is sensible to do so. See: [[commands:​builtin:​eval]] and [[http://​mywiki.wooledge.org/​BashFAQ/​048 | Eval command and security issues]]. |+|''​eval'' ​ |Depends. Often code can be restructured to use better alternatives. ​ |''​eval''​ is thrown in here for good measure, as sadly it is so often misused that any use of ''​eval''​ (even the rare clever one) is immediately dismissed as wrong by experts, and among the most immediate solutions abused by beginners. In reality, there are correct ways to use ''​eval'',​ and even cases in which it's necessary, even in sophisticated shells like Bash and Ksh. ''​eval''​ is unusual in that it is less frequently appropriate in more feature-rich shells than in more minimal shells like Dash, where it is used to compensate for more limitations. If you find yourself needing ''​eval''​ too frequently, it might be a sign that you're either better off using a different language entirely, or trying to borrow an idiom from some other paradigm that isn't well suited to the shell language. By the same token, there are some cases in which working too hard to avoid ''​eval''​ ends up adding a lot of complexity and sacrificing all portability. ​Don't substitute a clever ''​eval''​ for something that's a bit "too clever",​ just to avoid the ''​eval'', ​yet, take reasonable measures to avoid it where it is sensible to do so. See: [[commands:​builtin:​eval]] and [[http://​mywiki.wooledge.org/​BashFAQ/​048 | Eval command and security issues]]. |
  
 ===== See also ===== ===== See also =====