[Rd] Some packages have non-POSIX-compliant shell scripts. Implement a CRAN check for bashisms?
Dear R-devel, Recently I ran into trouble installing two separate packages, nloptr and ncdf4, both due to the same issue: they have scripts that have the shebang `#! /bin/sh', but have bashisms in them, i.e. non-POSIX-compliant bash scripts. I use dash [1] as my shell environment, since it's about 4x as fast as bash. It looks like it's recently also become the default shell for Debian (and thus Ubuntu). It took quite a while to figure out what the issue was in great collaboration with the author of ncdf4 (CC). Perhaps it would be good to implement the utility checkbashisms [2] into the CRAN make pipeline to help discover these kinds of issues? Running `checkbashisms -f pkg/configure` on files that have the `#! /bin/sh` shebang gives useful information about which lines of code are secretly bash code, with some hints on how to make them POSIX-compliant. The alternative would of course be to change the shebang into `#! /bin/bash`. Kind regards, Ilja Kocken [1]: http://gondor.apana.org.au/~herbert/dash/ [2]: https://packages.qa.debian.org/d/devscripts.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Some packages have non-POSIX-compliant shell scripts. Implement a CRAN check for bashisms?
Your report underlines the importance of the checks implemented by CRAN.
In fact, checkbashisms has become an optional part of R CMD check in R
4.0.0, whose NEWS say
> R CMD check now optionally checks configure and cleanup scripts for
> non-Bourne-shell code ('bashisms').
The R Internals manual at
https://cran.r-project.org/doc/manuals/r-devel/R-ints.html reveals that
the corresponding environment variable is called "_R_CHECK_BASHISMS_".
It is false by default but true for CRAN submission checks (--as-cran),
except on Windows. The check is probably not enabled for the routine
checks on the CRAN check farm.
Am 05.11.20 um 11:15 schrieb Kocken, I.J. (Ilja):
> Dear R-devel,
>
> Recently I ran into trouble installing two separate packages, nloptr and
> ncdf4, both due to the same issue: they have scripts that have the shebang
> `#! /bin/sh', but have bashisms in them, i.e. non-POSIX-compliant bash
> scripts.
>
> I use dash [1] as my shell environment, since it's about 4x as fast as bash.
> It looks like it's recently also become the default shell for Debian (and
> thus Ubuntu).
>
> It took quite a while to figure out what the issue was in great collaboration
> with the author of ncdf4 (CC).
>
> Perhaps it would be good to implement the utility checkbashisms [2] into the
> CRAN make pipeline to help discover these kinds of issues? Running
> `checkbashisms -f pkg/configure` on files that have the `#! /bin/sh` shebang
> gives useful information about which lines of code are secretly bash code,
> with some hints on how to make them POSIX-compliant. The alternative would of
> course be to change the shebang into `#! /bin/bash`.
>
> Kind regards,
>
> Ilja Kocken
>
>
>
> [1]: http://gondor.apana.org.au/~herbert/dash/
> [2]: https://packages.qa.debian.org/d/devscripts.html
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Named class vector
The source to the noquote() function looks like this:
noquote <- function(obj, right = FALSE) {
## constructor for a useful "minor" class
if(!inherits(obj,"noquote"))
class(obj) <- c(attr(obj, "class"),
if(right) c(right = "noquote") else "noquote")
obj
}
Notice what happens with right = TRUE:
> x <- noquote("a", right = TRUE)
> x
[1] a
> class(x)
right
"noquote"
The class vector for x is named. The print method pays attention to the
name, so we get different behaviour for a class of "noquote" and a class
of c(right = "noquote").
I had never noticed a named class vector before, and it raised some
questions for me:
- Is this used anywhere else?
- Are names preserved in all the operations normally done on a class
vector? (As far as I can see they are, but maybe I've missed something.)
- Is it a good idea to encode a string value worth of information in the
name, rather than setting the class to something like c("noquote",
"right") instead?
Comments would be welcome.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Named class vector
> Duncan Murdoch writes:
> The source to the noquote() function looks like this:
> noquote <- function(obj, right = FALSE) {
> ## constructor for a useful "minor" class
> if(!inherits(obj,"noquote"))
> class(obj) <- c(attr(obj, "class"),
> if(right) c(right = "noquote") else "noquote")
> obj
> }
> Notice what happens with right = TRUE:
>> x <- noquote("a", right = TRUE)
>> x
> [1] a
>> class(x)
> right
> "noquote"
> The class vector for x is named. The print method pays attention to the
> name, so we get different behaviour for a class of "noquote" and a class
> of c(right = "noquote").
> I had never noticed a named class vector before, and it raised some
> questions for me:
> - Is this used anywhere else?
Not that I'd be aware of: I think MMae is the expert here.
> - Are names preserved in all the operations normally done on a class
> vector? (As far as I can see they are, but maybe I've missed something.)
> - Is it a good idea to encode a string value worth of information in the
> name, rather than setting the class to something like c("noquote",
> "right") instead?
My preference would be to have unnamed class vectors, so that the names
could perhaps eventually be used to store the name of the package which
owns the class. For noquote, I guess you'd want something like
c("noquote_right", "noquote")
Best
-k
> Comments would be welcome.
> Duncan Murdoch
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
