expr

The expr utility shall evaluate an expression and write the result to standard output. The single expression evaluated by expr shall be formed from the operand operands, as described in the EXTENDED DESCRIPTION section. The application shall ensure that each of the expression operator symbols: Provide a default value for the internationalization variables that are unset or null. (See XBD Internationalization Variables for the precedence of internationalization variables used to determine the values of locale categories.) If set to a non-empty string value, override the values of all the other internationalization variables. Determine the locale for the behavior of ranges, equivalence classes, and multi-character collating elements within regular expressions and by the string comparison operators. Determine the locale for the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters in arguments) and the behavior of character classes within regular expressions. Determine the locale that should be used to affect the format and contents of diagnostic messages written to standard error. [XSI) ] ![[Option Start]]( Determine the location of message catalogs for the processing of LC MESSAGES. ![[Option End]]( The expr utility shall evaluate the expression and write the result, followed by a , to standard output. The formation of the expression to be evaluated is shown in the following table. The symbols expr , expr1 , and expr2 represent expressions formed from integer and string symbols and the expression operator symbols (all separate arguments) by recursive application of the constructs described in the table. The expressions are listed in order of decreasing precedence, with equal-precedence operators grouped between horizontal lines. All of the operators shall be left-associative. In many cases, the arithmetic and string features provided as part of the shell command language are easier to use than their equivalents in expr . Newly written scripts should avoid expr in favor of the new features within the shell; see Parameters and Variables and Arithmetic Expansion . as the arguments are passed to expr (and they all may be taken as the '=' operator). The following works reliably: Also note that this volume of POSIX.1-2017 permits implementations to extend utilities. The expr utility permits the integer arguments to be preceded with a unary minus. This means that an integer argument could look like an option. Therefore, the conforming application must employ the "--" construct of Guideline 10 of XBD Utility Syntax Guidelines to protect its operands if there is any chance the first operand might be a negative integer (or any string with a leading minus). For testing string equality the test utility is preferred over expr , as it is usually implemented as a shell built-in. However, the functionality is not quite the same because the expr = and != operators check whether strings collate equally, whereas test checks whether they are identical. Therefore, they can produce different results in locales where the collation sequence does not have a total ordering of all characters (see XBD LC COLLATE ). is a better representation of the previous example. The addition of the "//" characters eliminates any ambiguity about the division operator and simplifies the whole expression. Also note that pathnames may contain characters contained in the IFS variable and should be quoted to avoid having "$a" expand into multiple arguments. In an early proposal, EREs were used in the matching expression syntax. This was changed to BREs to avoid breaking historical applications. return 3 and 0, respectively, on those systems; their documentation would imply the reverse. Thus, the anchoring condition is left unspecified to avoid breaking historical scripts relying on this undocumented feature. The expr utility is aligned with the IEEE P1003.2b draft standard, to include r