>>>>> 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 Solaris 10 '/bin/sh') don't support it. motivating the code shown below. Perhaps simplest to always use expr. -k> 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=`expr "$@"` > } > fi> 2017-12-17 23:55 GMT+01:00 Rodrigo Tobar <rtobar at icrar.org>: >> 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 absolutely true, and also that the manual >> warns about this, which is true again. So far everything is clear. >> >> However, what confuses me is that even when the manual says that "you can >> include an executable (Bourne) shell script configure in your package" [1], >> the associated footnote says something slightly different: "The script >> should only assume a POSIX-compliant /bin/sh" [2]. The footnote goes even >> further, and links to the POSIX specification of the Shell Command Language >> [3] (as published by The Open Group), which explicitly includes arithmetic >> expressions like the one above in its syntax [4]. >> >> My question then is: what exact dialect should be considered? Given that the >> statement above does not work in the Bourne shell, I conclude that the >> Bourne shell is not POSIX-compliant. That in turn would make the manual >> ambiguous as to the precise dialect that should be used by our configure >> scripts, and either the shells used by R should be changed to be >> POSIX-compliants, or the manual edited to be more precise regarding . >> >> Many thanks. >> >> Rodrigo >> >> [1] >> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup >> [2] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT25 >> [3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html >> [4] >> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04 >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel> -- > I?aki ?car > http://www.enchufa2.es > @Enchufa2> ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
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)
<https://en.wikipedia.org/wiki/Solaris_(operating_system)#Post-Oracle_closed_source_(Solaris_10_after_March_2010,_and_Solaris_11_(2011_and_later))>
since
March 2010.
On Mon, Dec 18, 2017 at 1:23 PM, Kurt Hornik <Kurt.Hornik at wu.ac.at>
wrote:
> >>>>> 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
> Solaris 10 '/bin/sh') don't support it.
>
> motivating the code shown below. Perhaps simplest to always use expr.
>
> -k
>
>
> > 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=`expr "$@"`
> > }
> > fi
>
> > 2017-12-17 23:55 GMT+01:00 Rodrigo Tobar <rtobar at icrar.org>:
> >> 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 absolutely true, and also that
the
> manual
> >> warns about this, which is true again. So far everything is clear.
> >>
> >> However, what confuses me is that even when the manual says that
"you
> can
> >> include an executable (Bourne) shell script configure in your
package"
> [1],
> >> the associated footnote says something slightly different:
"The script
> >> should only assume a POSIX-compliant /bin/sh" [2]. The
footnote goes
> even
> >> further, and links to the POSIX specification of the Shell Command
> Language
> >> [3] (as published by The Open Group), which explicitly includes
> arithmetic
> >> expressions like the one above in its syntax [4].
> >>
> >> My question then is: what exact dialect should be considered?
Given
> that the
> >> statement above does not work in the Bourne shell, I conclude that
the
> >> Bourne shell is not POSIX-compliant. That in turn would make the
manual
> >> ambiguous as to the precise dialect that should be used by our
configure
> >> scripts, and either the shells used by R should be changed to be
> >> POSIX-compliants, or the manual edited to be more precise
regarding .
> >>
> >> Many thanks.
> >>
> >> Rodrigo
> >>
> >> [1]
> >> https://cran.r-project.org/doc/manuals/r-release/R-exts.
> html#Configure-and-cleanup
> >> [2]
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT25
> >> [3] http://pubs.opengroup.org/onlinepubs/9699919799/
> utilities/V3_chap02.html
> >> [4]
> >> http://pubs.opengroup.org/onlinepubs/9699919799/
> utilities/V3_chap02.html#tag_18_06_04
> >>
> >> ______________________________________________
> >> R-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> > --
> > I?aki ?car
> > http://www.enchufa2.es
> > @Enchufa2
>
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
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 wanted to be able to support the cutting edge. Now things seem to converge on a few variations on the big three: Windows, MacOS, Linux, possibly on some parallel/cloud infrastructure. However, it is probably worth maintaining the conservative defensive policies at least for a while yet. (I suspect that the text in WRE is actually older than the current POSIX standard, which is what causes confusion as to what constitutes a Bourne shell. It may be worth editing it to say that we are in fact more restrictive than current POSIX.) -pd> On 18 Dec 2017, at 23:36 , Paul McQuesten <mcquesten at gmail.com> wrote: > > 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) > <https://en.wikipedia.org/wiki/Solaris_(operating_system)#Post-Oracle_closed_source_(Solaris_10_after_March_2010,_and_Solaris_11_(2011_and_later))> > since > March 2010. > > On Mon, Dec 18, 2017 at 1:23 PM, Kurt Hornik <Kurt.Hornik at wu.ac.at> wrote: > >>>>>>> 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 >> Solaris 10 '/bin/sh') don't support it. >> >> motivating the code shown below. Perhaps simplest to always use expr. >> >> -k >> >> >>> 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=`expr "$@"` >>> } >>> fi >> >>> 2017-12-17 23:55 GMT+01:00 Rodrigo Tobar <rtobar at icrar.org>: >>>> 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 absolutely true, and also that the >> manual >>>> warns about this, which is true again. So far everything is clear. >>>> >>>> However, what confuses me is that even when the manual says that "you >> can >>>> include an executable (Bourne) shell script configure in your package" >> [1], >>>> the associated footnote says something slightly different: "The script >>>> should only assume a POSIX-compliant /bin/sh" [2]. The footnote goes >> even >>>> further, and links to the POSIX specification of the Shell Command >> Language >>>> [3] (as published by The Open Group), which explicitly includes >> arithmetic >>>> expressions like the one above in its syntax [4]. >>>> >>>> My question then is: what exact dialect should be considered? Given >> that the >>>> statement above does not work in the Bourne shell, I conclude that the >>>> Bourne shell is not POSIX-compliant. That in turn would make the manual >>>> ambiguous as to the precise dialect that should be used by our configure >>>> scripts, and either the shells used by R should be changed to be >>>> POSIX-compliants, or the manual edited to be more precise regarding . >>>> >>>> Many thanks. >>>> >>>> Rodrigo >>>> >>>> [1] >>>> https://cran.r-project.org/doc/manuals/r-release/R-exts. >> html#Configure-and-cleanup >>>> [2] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT25 >>>> [3] http://pubs.opengroup.org/onlinepubs/9699919799/ >> utilities/V3_chap02.html >>>> [4] >>>> http://pubs.opengroup.org/onlinepubs/9699919799/ >> utilities/V3_chap02.html#tag_18_06_04 >>>> >>>> ______________________________________________ >>>> R-devel at r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> >> >>> -- >>> I?aki ?car >>> http://www.enchufa2.es >>> @Enchufa2 >> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel-- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com