Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
commands:builtin:let [2012/11/03 08:34] techlivezheng [Examples] |
commands:builtin:let [2015/11/16 04:19] (current) thebonsai [The let builtin] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== The let builtin ====== | + | ====== The let builtin command ====== |
| ===== Synopsis ===== | ===== Synopsis ===== | ||
| Line 50: | Line 50: | ||
| ===== Portability considerations ===== | ===== Portability considerations ===== | ||
| - | * the ''let'' command is not specified by POSIX(r). The portable alternative is: <code>[ "$(( <EXPRESSION> ))" -ne 0 ]</code> | + | * the ''let'' command is not specified by POSIX(r). The portable alternative is: <code>[ "$(( <EXPRESSION> ))" -ne 0 ]</code>. To make portable scripts simpler and cleaner, ''let'' can be defined as: <code> |
| + | # POSIX | ||
| + | let() { | ||
| + | IFS=, command eval test '$(($*))' -ne 0 | ||
| + | } | ||
| + | </code> Aside from differences in supported arithmetic features, this should be identical to the Bash/Ksh ''let''. | ||
| + | * It seems to be a common misunderstanding that ''let'' has some legacy purpose. Both ''let'' and [[syntax/ccmd/arithmetic_eval | ((...))]] were ksh88 features and almost identical in terms of portability as everything that inherited one also tended to get the other. Don't choose ''let'' over ''(('' expecting it to work in more places. | ||
| * [[http://pubs.opengroup.org/onlinepubs/9699919799/utilities/expr.html#tag_20_42 | expr(1)]] is a command one is likely to come across sooner or later. While it is more "standard" than ''let'', the above should always be preferred. Both [[syntax:arith_expr | arithmetic expansion]]s and the ''['' test operator are specified by POSIX(r) and satisfy almost all of expr's use-cases. Unlike ''let'', ''expr'' cannot assign directly to bash variables but instead returns a result on stdout. ''expr'' takes each operator it recognizes as a separate word and then concatenates them into a single expression that's evaluated according to it's own rules (which differ from shell arithmetic). ''let'' parses each word it recieves on its own and evaluates it as an expression without generating any output other than a return code. | * [[http://pubs.opengroup.org/onlinepubs/9699919799/utilities/expr.html#tag_20_42 | expr(1)]] is a command one is likely to come across sooner or later. While it is more "standard" than ''let'', the above should always be preferred. Both [[syntax:arith_expr | arithmetic expansion]]s and the ''['' test operator are specified by POSIX(r) and satisfy almost all of expr's use-cases. Unlike ''let'', ''expr'' cannot assign directly to bash variables but instead returns a result on stdout. ''expr'' takes each operator it recognizes as a separate word and then concatenates them into a single expression that's evaluated according to it's own rules (which differ from shell arithmetic). ''let'' parses each word it recieves on its own and evaluates it as an expression without generating any output other than a return code. | ||
| - | |||
| * For unknown reasons, ''let'' is one of the Bash commands with special parsing for arguments formatted like compound array assignments. See: [[commands/builtin/eval#portability_considerations | eval]] for details. There are no known practical uses for this. Parentheses are treated as grouping operators and compound assignment is not possible by arithmetic expressions. | * For unknown reasons, ''let'' is one of the Bash commands with special parsing for arguments formatted like compound array assignments. See: [[commands/builtin/eval#portability_considerations | eval]] for details. There are no known practical uses for this. Parentheses are treated as grouping operators and compound assignment is not possible by arithmetic expressions. | ||