Categoria: Tecnologia

Como resolver o erro “xcrun: error: invalid active developer path” no macOS

Todos sabem que uso um Mac como ferramenta de trabalho e num determinado dia, resolvi que era hora de atualizar minha máquina para a versão mais nova do macOS.

Muito bem, fiz a atualização e continuei trabalhando normalmente por uns bons dias, até que fui usar o Git para criar um novo repositório na minha máquina e recebi um erro que eu não tinha visto ainda:

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

Para quem está acostumado com o Xcode, deve saber que o xcrun é um utilitário permite que se rode diversas ferramentas do Xcode por linha de comando. Olhando a mensagem de erro, pode-se deduzir que o Xcode não está instalado na máquina.

Eu tinha estas ferramentas instaladas, mas pelo visto, o instalador da nova versão do macOS simplesmente apagou tudo e esqueceu de reinstalá-las, apesar de manter o resto todo no lugar.

Ainda bem que a solução é simples: basta reinstalar o Xcode baixando o instalador do portal de desenvolvedores da Apple (https://developer.apple.com/downloads/).

Se tu não usas o pacote completo, não é necessário baixar este arquivo, basta rodar o seguinte na linha de comando:

xcode-select --install
Escolhe [Obter Xcode] para baixar o pacote completo ou [Instalar] só para as ferramentas de linha de comando.

O sistema vai abrir um diálogo para tu escolheres baixar todo o Xcode (“Obter Xcode”) ou só as ferramentas de linha de comando (“Instalar”).

Seguem-se as confirmações e o aceite da licença de uso, como de praxe, e tudo necessário será instalado, inclusive o Git, é claro. Depois disso, a ferramenta vai voltar a funcionar novamente.

Como atualizar o PHP no macOS?

Se tu usas Mac para desenvolver teus sítios WordPress, deves ter notado que felizmente o macOS já vem com o PHP instalado. A questão é que nem sempre a versão instalada é a mais nova, principalmente se estás rodando uma versão antiga do macOS, como eu, que uso o El Capitan no meu Mac Pro 2009.

Ter a última versão PHP é um pré-requisito para poderes desenvolver teus projetos e uma versão antiga pode ficar atrapalhando tua vida, principalmente se queres usar ferramentas auxiliares como a extensão PHP Intellisense dentro do VSCode.

O macOS Catalina já vem com a versão 7.3 do PHP, e o Mojave e o High Sierra até vêm com o PHP 7.1 pré-instalado, mas a versão instalada no macOS Sierra é a 5.6 e o El Capitan vem com o PHP 5.5. Péssimo.

Felizmente o pessoal do grupo php-osx mantém pacotes dos últimos “builds” das versões do PHP desde a 5.3 até 7.3, que podem ser instalados desde o Snow Leopard (OS X 10.6) até o High Sierra (macOS 10.13). Como os programas são instalados na pasta /usr/local/php5, eles não afetam em nada tua instalação padrão do macOS.

Instalando o PHP no macOS

Mais fácil que correr cancha com tropeiro de lesma. Escolhe a versão, abre o Terminal e digita a linha correspondente, abaixo:

PHP 7.3

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 7.3

PHP 7.2

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 7.2

PHP 7.1

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 7.1

PHP 5.6

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 5.6

Infelizmente o pessoal do php-osx não montou um pacote para a versão 7.4 e ainda não descobri uma maneira mais fácil de instalar esta versão sem ter que instalar utilitários extras, como o Homebrew. Quando descobrir, atualizo o artigo.

Verificando se a nova versão do PHP está funcionando

Agora que tudo está instalado, precisamos adicionar a pasta do pacote ao PATH do sistema:

$ export PATH=/usr/local/php5/bin:$PATH

Depois, é só verificar se a nova versão é a padrão:

Mac-Pro:~ marcoandrei$ php -v

PHP 7.3.8 (cli) (built: Aug 11 2019 20:50:16) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.8, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.8, Copyright (c) 1999-2018, by Zend Technologies
with Xdebug v2.7.2, Copyright (c) 2002-2019, by Derick Rethans

Feito!

“Tá, mas o VS Code continua dando erro…”

Pois é, em alguns casos, quando o VS Code continua dando erro, é porque a extensão PHP Intellisense não identificou corretamente a versão do PHP, mesmo que o sistema aponte a versão nova. A solução é preencher o parâmetro “executablePath” nas configurações da extensão.

Dentro do VS Code, vai em Extensions e encontra a extensão “PHP Intellisense”. Clica na engrenagem e seleciona Extension Settings. Adiciona (ou edita) esta linha no arquivo settings.json:

"php.executablePath": "/usr/local/php5/bin/php"

Agora sim!

Bueno, este tutorial te ajudou? Tens alguma dúvida? Deixa teu comentário aí embaixo e a gente troca uma ideia!

SSH: Como forçar o uso de senha para autenticação?

Para desenvolvedores que têm conhecimento de infraestrutura e gostam de manter seu próprio servidor, usar o SSH para acessá-lo e fazer manutenções no WordPress e outras pastas é uma tarefa cotidiana. Normalmente o acesso se dá com a dupla usuário/senha, mas há casos, entretanto, em que a plataforma obriga ou já deixa o servidor pré-configurado para fazer o acesso somente por uma chave pública SSH.

Quando o acesso SSH por chave pública atrapalha

O acesso por chave pública é uma opção segura, mas pode ser um problema se tu não tens conhecimento dessa chave ou não estavas preparado para este tipo de acesso.

Nestes casos, ao se tentar acessar o servidor com o comando ssh usuario@servidor, recebemos aquele erro chato e sem muita explicação:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)

Isso normalmente ocorre porque o SSH está tentando fazer a combinação de autenticação e a chave não está armazenada em tua máquina, simplesmente porque não existe.

Um exemplo comum são servidores criados nos serviços Lightsail ou EC2 da Amazon. Nestes serviços, os servidores não tem um usuário “root” e o acesso por padrão é via chave pública. Para melhorar, a documentação não é clara sobre este aspecto da configuração (até porque é quase toda em Inglês).

No caso da Umbler, é um pouco diferente. A documentação é melhor e o suporte é amistoso, o que já melhora 100%. Entretanto, para se fazer o acesso SSH é obrigatório fazer o envio da chave pública antes, não há a opção de acessar por senha.

Já na DigitalOcean, Vultr e outras, em geral é possível ter o acesso via chave pública, mas a autenticação padrão é por senha, o que pode ser menos seguro, mas é mais prático logo que se cria o servidor.

O que fazer?

O que fazer nestes casos? Na verdade é simples. Basta usar os parâmetros PreferredAuthentications (Autenticação Preferida) e PubkeyAuthentication (Autenticação por Chave Pública) para forçar o acesso por senha e dispensar a chave pública.

O comando ficaria assim:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no usuario@servidor

Ou seja, “Autenticação Preferida = senha” e “Autenticação por Chave Pública = não”.

Com esse comando, o SSH vai responder com:

usuario@servidor's password:

Daí é só entrar com a senha e pronto.

Tenha configurações SSH diferentes para cada servidor

Outra possibilidade interessante é guardar as configurações usadas para cada servidor que precisares fazer acesso.

Isso é feito por meio de um arquivo “config” que é gravado na pasta .ssh, a mesma onde ficam as chaves de acesso.

Criando um arquivo de configurações para o SSH

1) Acessa a pasta .ssh na tua pasta de usuário e cria um documento com o nome config e ajusta as permissões do arquivo para 600.

2) Edita o arquivo e cria seções iniciando sempre com este modelo

host <servidor ou padrão>

Por exemplo:

host *.gauderio.com
user gaudencio
port 9191
PubkeyAuthentication=no

Daí é só usar ssh indio-veio.gauderio.com que o SSH vai consultar o arquivo de configurações e aplicar as opções listadas acima.

Ainda há a chance de haver um arquivo de configuração padrão para todo o sistema. Neste caso, será necessário “enganar” o SSH, especificando uma configuração de mentirinha:

ssh -F /dev/null usuario@servidor

O parâmetro -F permite especificar um arquivo de configuração alternativo e a configuração padrão de sistema é ignorada.

Este artigo te ajudou? Ficaste com alguma dúvida sobre o SSH? Seguiste os passos e não funcionou? Deixa teu comentário aí embaixo para a gente ver juntos!

O PHP morreu. Viva o PHP!

Apesar de estar em mais de 80% dos sítios na Web, incluindo Facebook e Wikipédia, os detratores continuam dizendo que o PHP morreu. Será mesmo?

Estes tempos estava conversando com um grupo de colegas de um curso e alguém me declara: “mas o PHP está morrendo, né?”.

Acho engraçado isso. Mais do que isso, acho engraçado aquele pessoal vive na busca sôfrega por duas coisas: “qual/quem é o melhor?” e “qual/quem é o moribundo?”. Toda a vez que surge uma nova tecnologia, a galera fica desesperada para que ela seja a “ferramenta definitiva”, matando tudo que tem em volta. Pois a bola da vez parece ser o PHP.

Eu trabalho com o PHP desde um pouco antes de começar com o WordPress. O WordPress é feito em PHP e pretende continuar usando a linguagem em longo prazo, o que me faz pensar rapidamente que: NÃO, O PHP NÃO MORREU.

E antes de alguém dizer “mas…” vou apelar para as estatísticas da W3Techs:

OITENTA E TRÊS POR CENTO de presença na Internet. Parece pouco?

“Ah, mas porque tem um monte de CMS feito em PHP e a estatística fica distorcida!” Muito bem, Mike Oram em seu artigo “Is PHP relevant” nos conta que mesmo sem os CMSs, o PHP continua com 54% da Web. Adicione-se a isso o fato de sítios como Facebook, Ali Express, Wikipedia e outros terem escolhido o PHP como ferramenta de desenvolvimento. Parece irrelevante?

E a tendência do uso de PHP não é de baixa, ao contrário, a linguagem chegou a AUMENTAR levemente sua presença no último ano, como podemos ver neste gráfico também da W3Techs.

Acho que isso é o suficiente para provar que apesar dos seus detratores e “haters”, o PHP continua firme e forte há mais de 20 anos (foi lançada em 1995).

Claro que a linguagem tem suas “falhas” ou “problemas”, como alguém pode dizer, dizendo que tem erros ou indicando que é fracamente tipada, por exemplo. Pois para o primeiro argumento, sugiro se atualizar, pois ainda em 2009 a versão 5.3 resolveu a maioria dos “bugs tradicionais” encerrando de vez o assunto. E para o segundo, bem, eu considero uma VANTAGEM, que um bom programador saberá usar a seu favor!

Já estamos na versão 7.2 e posso dizer que a linguagem só melhora, com um salto incrível de velocidade a partir da versão 7 (tanto que se pulou da versão 5.6 para a 7.0 direto!).

Ainda não te convenceste? Te dou uma dica: lê o artigo “7 linguagens de programação que todo o desenvolvedor deveria aprender em 2018” da TechRepublic. O PHP está lá, só para constar.