Re: [Rd] Dialect for shell scripts

Hi all, Thanks to all for your responses. As pointed out by a few of you, using expr is indeed safer, and is what we ended up using in our script to get it accepted in CRAN. On 19/12/17 07:26, peter dalgaard wrote: (I suspect that the text in WRE is actually older than the current POSIX sta

Re: [Rd] Dialect for shell scripts

Solaris is pretty much dead at this point (closed source or not), but it is not the only oddball OS around. The need to support a wide palette of (Unix) OS variations has been rapidly declining in later years. Fifteen years ago every supercomputer seemed to have its own set of OS quirks and we

Re: [Rd] Dialect for shell scripts

I do not have a dog in this fight, but I have to ask: How much person time is worthwhile to invest in supporting Solaris 10? It has been closed-source (Post-Oracle)

Re: [Rd] Dialect for shell scripts

> Iñaki Úcar writes: Same from here: in addition to what the standards say, it always pays to be defensive and check "Portable Shell Programming" in the Autoconf manual. Among other things, this says '$((EXPRESSION))' Arithmetic expansion is not portable as some shells (most notably

Re: [Rd] Dialect for shell scripts

For what it's worth, Autoconf does not assume that arithmetic expansion will be available. Instead, it emits the following shell code: if ( eval 'test $(( 1 + 1 )) = 2' ) 2>/dev/null; then eval 'func_arith () { func_arith_result=$(( $* )) }' else func_arith () { func_arith_result

[Rd] Dialect for shell scripts

Dear all, During a recent package submission, we were highlighted that some lines in our configure script didn't follow the correct syntax. The lines looked like this: x=$(($y/10)) We were indicated at the time that this is because the statement does not use Bourne shell syntax, which is ab