Devtools: erro de função de liberação

link simbólico funcionou para mim (referência: http://apple.stackexchange.com/questions/106189/missing-usr-bin-gnutar-on-mavericks-macports/106209#106209)

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

Fechando por enquanto, pois não acho que isso seja um problema de devtools.

Eu estava tendo o mesmo problema, mas com 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 a Apple se livrou de /usr/bin/gnutar no OS X 10.9 (Mavericks).

Isso resolveu o problema e agora check() passa sem erros: http://day-to-day-stuff.blogspot.com/2013/11/installing-gnutar-on-maverick.html

Estou no OS X 10.9.1 com R 3.0.2 e devtools 1.4.1.99.

Para qualquer futuro google'ers que vier parar aqui como eu, na verdade tive um problema semelhante ao usar devtools para instalar o xml2 por meio do repositório git.

Este é o comando e o erro que recebi no Ubuntu 14.04.5 em uma caixa AWS EC2 executando o Anaconda r-essentials como a distribuição R 3.2.2:
devtools :: install_git ("git: //github.com/hadley/xml2.git", branch = "master")
Instalando xml2
tentando URL http://cran.rstudio.com/src/contrib/BH_1.60.0-2.tar.gz
Tipo de conteúdo aplicativo / comprimento x-gzip 9783419 bytes (9,3 MB)
baixado 9,3 MB
sh: 1: / bin / gtar: não encontrado

Para consertar, tentei algo semelhante ao trabalho funcionou para @sckott acima:
sudo ln -s /bin/tar /bin/gtar
Com certeza, vincular gtar ao alcatrão real funcionou, e a instalação foi perfeita depois disso.

Certeza que isso não tem nada a ver com quaisquer bugs no devtools ou xml2, mas algo que é estranho com o meu PATH e o Anaconda R tendo algo a ver com isso, mas isso funcionou para nós.

Só para adicionar mais uma prova do que @ GISDev01 mencionou (já que sou um desses futuros googlers), Sys.getenv("TAR") por meio de utils::untar é o culpado, pelo menos no meu caso. Essa chamada getenv retorna / bin / gtar em meu sistema por algum motivo. (Tudo isso está dentro de uma instalação R fornecida pelo Anaconda; ele retorna o caminho correto ao usar o pacote R fornecido pelo sistema operacional.)

Uma correção simples que funcionou para mim e não requer acesso root foi apenas fazer export TAR=/bin/tar no shell antes de iniciar R. Então Sys.getenv("TAR") apenas retorna a variável de ambiente real em vez de fazer o que quer que seja mágica que ele faz para tentar descobrir isso, e devtools pode descompactar suas dependências durante a instalação.

Para tornar isso ainda mais simples para pessoas com esse problema, chamar o seguinte em R resolveu esse problema para mim sem ter que sair do R, mudar meu caminho, sudo, etc:

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

Este problema antigo foi bloqueado automaticamente. Se você acredita que encontrou um problema relacionado, registre um novo problema (com reprex) e crie um link para esse problema. https://reprex.tidyverse.org/