 |
Bug no terminal de comandos Bash e comparação entre os pacotes de coleções de comandos |
Fiz uso na época de alguns terminais (que não me lembro o nome) e um deles era o terminal Bash para o Android. O Bash retornava valor errado de horas em execução pelo comando uptime, não combinava com o relógio do android e nem com dos outros terminais que estavam sendo utilizados. Foi aí que passei a me preocupar se todo resultado obtivermos no terminal são verídicos ou não, e por isso adotei a estratégia de conferir os resultados em dois ou mais terminais de tempos em tempos somente para me certificar.
Consegui recuperar as imagens da época que fiz a analise e aqui estão algumas mostrando a quanto tempo o sistema está em funcionamento tanto pelo sistema de estado do próprio android quanto pelo bash fazendo uso do comando uptime:
Reparem nas duas primeiras imagens que o android já estava no em funcionamento hà mais de 252 horas (10 dias e meio) enquanto que o bash informa que o sistema está em funcionamento a somente 8 dias e 3 horas.
Reparem agora nesta duas que o android consta mais de 254 horas (e está correto de acordo com o relógio exibido no canto superior direito sendo o total de 10 dias e 14 horas) enquanto que o bash permanece 8 dias e 4:36.
Tudo bem, foram no mesmo dia, então esperei mais um tempo e agora o android consta mais de 273 horas (totalizando de 11 dias e 9 horas e meia) enquanto que o Bash permanece 8 dias e 23:05. Nesta ultima imagem, conferam a data e hora com o comando
date que e o bash retornou 21:10 sendo que a hora real era 18:10).
Eu não sou o único que já reparou isso, esta imagem abaixo é de um membro do
grupo Linux aprendendo no Telegram onde relata que a partição /dev/sda4 pelo gparted está em NTFS enquanto que no Bash consta FAT16 a mesma partição. Porém o Windows também reconhece como NTFS:
 |
| Confiram o o sistema de arquivos no partição /dev/sda4 fornecida pelo Gparted e pelo Bash. Esta imagem é na distribuição Kali Linux |
Esta ultima imagem é outra situação que aconteceu durante o processo de escrever este artigo. Eu utilizei o comando du (disk used) para conferir o tamanho final do binário do toybox após compilá-lo e o bash me retornou que o toybox tinha apenas 56k; repeti a operação e obtive o mesmo resultado. Depois utilizei o comando o du do próprio toybox que tenho instalado na minha máquina, para através dele também conferir o resultado final do tamanho do novo binário que compilei e o resultado foi que o comando du do toybox me retornou que seu tamanho final era de 328k (e não 56k como exibindo pelo du do coreutils...) Quando dos dois então estão certos? Após isso, para desencargo de consciência, resolvi mais uma vez utilizar o comando du do próprio bash que me retornou o valor de 328k e não 56k como ele havia me retornado das duas primeiras vezes... Bem conflitante. Não?
 |
| O comando du utilizado no bash (pacote coreutils) consta que o arquivo toybox é do tamanho de 56k, depois o mesmo comando no toybox e depois o mesmo comando no bash novamente |
Esta não é a primeira vez que situação assim acontece e considero até mesmo um alerta para a adoção de outros terminais como Zsh e Fish como terminal de comandos principal. Este é um bug de longa data que volta e meia acabo vendo.
Neste artigo resolvi comparar os pacotes coreutils do GNU, o embutils, o 9base e o toybox para certificar se estes entregam os mesmos resultados ou se retornam valores diferentes, tamanho final do binário, licença e muito mais.
Deu trabalho calcular o tamanho final do 9base uma vez que os comandos ficam todos dispersos estando cada um em seu próprio diretório (diretório = pasta para caso você que esteja lendo seja usuário novo no Linux) e cada diretório não contem unicamente o próprio comando (diferente do embutils que concentra todos os comandos em um único diretório quando compilados). Então criei um diretório, copiei somente os binários para dentro dele e assim calculei o tamanho final dos comandos do 9base.
 |
| Diretórios do 9base onde concentram os comandos sepadaramente. Clique na imagem para aumentar o tamanho. |
 |
| O diretório bin-x86_64 é aonde o embutils concentra todos os comanos após a compilação. Clique na imagem para aumentar o tamanho. |
As comparações aqui são feitas entre as licenças utilizadas, se são linkados dinamica ou estaticamente, o tamanho final dos binários, a descrição da saída da opção --help dos comandos para obter informações precisas de como utilizá-los e por fim o resultado das saídas dos comandos.
Utilizamos aqui os comandos df e du -s para verificar se os resultados coincidem; o único comando que não utilizamos no 9base foi o df, pois o 9base não possui tal comando. Os testes (básicos) aqui realizados usando comandos como du, foram feitos em diretórios como meu próprio home. No meu home mesmo por exemplo, enquanto o 9base retornou o resultado 12111218d (12113235d com a opção -sh... tipo... hein?), todos os outros retornaram o resultado 12244176 (12G com a opção -sh).
 |
| Clique na imagem para aumentar o tamanho. |
Os resultados pode ser conferidos logo abaixo:
 |
| Clique na imagem para aumentar o tamanho e conferir o resultado dos pacotes. |
Há quem vá dizer que não acha justo incluir o Bash nessa história; não seria então incluir o toybox também. Ou vai haver quem diga que não é justo incluir o toybox nesta comparação; a questão é que o toybox concentra todos os comandos dentro de si, e não dispersos. Fora que ele fez parte da série,
dando uma olhada ;)
Vale Lembrar também que o tamanho final dos arquivos pode variar por filesystem conforme descreve no artigo
Benchmark de filesystems.
De todos, o que menos me agradou foi literalmente o
9base. Não adianta o
9base estar sob a licença
MIT (
que é uma licença que vem tendo sua adição cada vez mais crescente) mas gerar binários exageradamente enormes, ter fracas descrições com a opção
--help e ainda apresentar resultados duvidosos e de difícil leitura (digitem o comando
ls do
9base e confiram que desastre).
Porém, também não adianta o
embutils ser tão pequeno (apesar que isso é muito bom :), tão exulto (admirável demais isso) e ter as mesmas fracas descrições na opção
--help que o
9base... (apesar que possuem manpages para os dois, essas descrições se tornam problemas fáceis de serem solucionados) e também adotar a
GPL mesmo que seja a versão 2. Poderia ao menos ter adotado a
MPL. Ao menos seu resultado não é duvidoso.
Também não adianta o
coreutils ter boas descrições com a opção
--help mas ter binários grandes (o coreutils não fica longe do
9base se consideráramos que o coreutils ser dinamicamente lincado) e adotar a
GPLv3 (versão totalmente conflitante com ao
GPLv2 e
GPLv2+). Fora seus resultados poderem ser bem duvidosos.
O que apresentou melhores resultados foi o realmente o
toybox podendo reunir as melhores características de cada um:
- Licença flexível para uma época onde a GPL se torna fragmentável
- tamanho final do binário bem enxuto (melhor que o próprio embutils)
- Pensado na segurança, estabilidade e desempenho
- Boa descrição de informações (de forma mais alinhada que do próprio Bash+coreutils)
- Resultado da saída do comando confiável
Uma pena ainda não ser possível utilizar o
toybox como terminal de comandos padrão como no caso do
Android, mas espero que não demore muito a se tornar uma opção para as distribuições que utilizamos (em especial o
Alpine Linux), o que é algo que a comunidade
toybox trabalha para que aconteça. Porque, ficar digitando o comando
toybox toda vez que quero usar um comando é desagastante. Na verdade ainda não abandono (de forma alguma) o
Zsh e está espero que venha a se tornar o terminal de comandos padrão nas distribuições.
Já perceberam que não coloquei o
coreutils como vilão da história como muitos
ACHAM que eu odeio
GNU. Porque a paixão excessiva por parte dos amantes do
Gnu em suas cabeças é tão grande que isso não permite que eles vejam que estou fazendo analise técnica. Porém também não estou escrevendo este artigo para desmoralizar o
9base. Somente não o adotaria hoje por não atender nenhuma das expectativas em um conjunto de comandos. Quando adotarem um terminal, pesem na balança se o que obtemos é real ou não. pretendo ainda fazer uma análise ainda um pouquinho maior sobre esse comandos. Vamos ver o que teremos de resposta ;)
E o estudo não para por aqui. Depois de quase concluído este artigo, descobri novas coisas que gerarão outro estudo. Até o próximo artigo.
Agradeço ao
Hilton Vasconcelos pela imagem fornecida do
Kali Linux mostrando a partição
/dev/sda4 no
Gparted e no
bash.
.jpg "V coreutils: Um coreutils escrito na linguagem V")
.png "Vinix: Um sistema operacional escrito na linguagem V")
.jpg "processo de compilação do V coreutils")
.jpg)
.jpg)
.jpeg)
