Devtools: error de función de liberación

el enlace simbólico funcionó para mí (referencia: http://apple.stackexchange.com/questions/106189/missing-usr-bin-gnutar-on-mavericks-macports/106209#106209)

sudo ln -s /usr/bin/tar /usr/bin/gnutar

Cerrando por ahora, ya que no creo que esto sea un problema de devtools.

Estaba teniendo el mismo problema, pero con check() :

Checking for any extra files in built .tar.gz file... sh: /usr/bin/gnutar: No such file or directory
Error in system(cmd, intern = TRUE) : error in running command

Parece que Apple se deshizo de /usr/bin/gnutar en OS X 10.9 (Mavericks).

Esto resolvió el problema y ahora check() pasa sin error: http://day-to-day-stuff.blogspot.com/2013/11/installing-gnutar-on-maverick.html

Estoy en OS X 10.9.1 con R 3.0.2 y devtools 1.4.1.99.

Para los futuros usuarios de Google que terminen aquí como yo, tuve un problema similar con el uso de devtools para instalar xml2 a través del repositorio de git.

Este es el comando y el error que estaba obteniendo en Ubuntu 14.04.5 en una caja de AWS EC2 que ejecuta Anaconda r-essentials como la distribución R 3.2.2:
devtools :: install_git ("git: //github.com/hadley/xml2.git", branch = "maestro")
Instalación de xml2
intentando URL http://cran.rstudio.com/src/contrib/BH_1.60.0-2.tar.gz
Tipo de contenido aplicación / longitud x-gzip 9783419 bytes (9,3 MB)
descargado 9.3 MB
sh: 1: / bin / gtar: no encontrado

Para solucionarlo, probé algo similar al trabajo que funcionó para @sckott arriba:
sudo ln -s /bin/tar /bin/gtar
Efectivamente, el enlace simbólico de gtar con el alquitrán real funcionó, y la instalación fue perfecta después de eso.

Estoy bastante seguro de que esto no tiene nada que ver con ningún error en devtools o xml2, pero algo que es extraño con mi PATH y Anaconda R teniendo algo, pero esto funcionó para nosotros.

Solo para agregar un poco más de prueba a lo que @ GISDev01 mencionó (ya que soy uno de esos futuros googlers), es Sys.getenv("TAR") por medio de utils::untar que tiene la culpa, al menos en mi caso. Esa llamada getenv devuelve / bin / gtar en mi sistema por alguna razón. (Todo esto está dentro de una instalación de R proporcionada por Anaconda; devuelve la ruta correcta cuando se usa el paquete R proporcionado por el sistema operativo).

Una solución simple que funcionó para mí y no requiere acceso de root fue simplemente hacer un export TAR=/bin/tar en el shell antes de iniciar R. Luego, Sys.getenv("TAR") simplemente devuelve la variable de entorno real en lugar de hacer lo que sea magia que hace para tratar de resolverlo, y devtools puede descomprimir sus dependencias durante la instalación.

Para que esto sea aún más simple para las personas con este problema, llamar a lo siguiente en R resolvió este problema sin tener que salir de R, cambiar mi ruta, sudo, etc.

Sys.setenv(TAR = "/bin/tar")

Este antiguo problema se ha bloqueado automáticamente. Si cree que ha encontrado un problema relacionado, presente un nuevo problema (con reprex) y enlace a este problema. https://reprex.tidyverse.org/