Bug no terminal de comandos Bash e comparação entre os pacotes de coleções de comandos

 Bom, fiz os vídeos onde demos uma olhada no toybox, Respondemos a comentários interessantes, demos uma olhada no embutils e no 9base. Depois disso me lembrei que no artigo "Android, uma boa alternativa ao Windows no desktop" que escrevi há mais ou menos dois anos atrás e que percebi um bug no Bash. A questão é que na época eu conferia a quanto tempo o android estava em funcionamento tanto pela configuração do sistema operacional quanto pelo comando uptime.

 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.

• Benchmark de filesystems
• Android - uma alternativa aos desktops
• A queda da GPL

Analisando 6 diferentes implementações do comando sed

Analisando e comparando seis diferentes implementações do comando sed

 Em abriu deste ano eu escrevi o artigo minised: Um sed melhor do que o sed. sed é um comando que como seu próprio nome sugere (Stream EDitor), serve para editar/alterar as informações que são exibidas em sua tela (observação que deve ser feita é que arquivos acessados através do sed não são modificados, apenas a forma como as informações são exibidas; a não ser que as informações exibidas sejam redirecionadas ao arquivo de origem). sed Foi um dos primeiros comandos desenvolvidos para o Unix para processamento de dados e, conforme o e-mail de lançamento do kernel Linux 0.02 "intitulado Códigos livres de kernel parecido com minix para AT-386" no grupo comp.os.minix, é descrito que sed também foi um dos primeiros comandos a ser utilizado pelo Linux:

"Ainda está na versão 0.02 (+1 (muito pequeno) patch já), mas executei com sucesso bash/gcc/gnu-make/gnu-sed/compress nele."

 O gnu-sed é a implementação utilizada na maioria das distribuições Linux porém, como existem diferentes implementações do mesmo comando (assim como existem diferentes implementações de todos os comandos e de todas as ferramentas), eu resolvi analisar e comparar ao menos seis delas apresentando aqui neste artigo os resultados de cada uma.

 Eu analisei o gnu-sed 4.8 disponível no Fedora 35 (sed-4.8-8.fc35.x86_64); o minised 1.16 já apresentado aqui no blog; o Busybox_SED que apesar de ter originado do gnu-sed, já não possui uma unica linha de código do do gnu-sed; logo não tendo mais nenhuma relação um com o outro (para entender melhor sobre esse caso, leia o meu artigo "O Paradoxo do Navio de Teseu no mundo open source" clicando aqui); as versões do toybox 0.8.6 e 0.8.7; o 9base sed (de origem do plan9 e depois portado para outros sistemas operacionais) e por fim o sbase sed de origem do Unix e portado para outros Unixes (incluindo Linux na lista de outros Unix) que não possui versão específica. Neste artigo eu irei avaliar as implementações por:

• Licença
• Tamanho do binário
• Recursos disponíveis
• descrição de ajuda
• Desempenho
• bugs

 Para os testes eu utilizei o terminal de comandos zsh por proporcionar melhores informações (inclusive uso de CPU por padrão) e devido o Bash por vezes já ter apresentado bugs que não podem nos garantir confiabilidade nos resultados (leia mais sobre os bugs que encontrei no bash clicando aqui). Em conjunto eu utilizei o comando time.

Diferença de exibição de resultados do comando time entre os terminais de comando bash e zsh.

 Fiz uso dos materiais públicos aurelio, the mouseless Dev que possui até mesmo um mapa mental muito interessante, o manual gnu-sed e os próprios arquivos de testes disponibilizados pelos próprios comandos.

Mapa mental do comando sed do site The Mouseless Dev

 Ao final de cada teste, eu irei classificar uma ou mais implementações como vencedores e na conclusão do artigo eu irei classificar da primeira a terceira colocação a partir da que proporcionar a maior quantidade de vantagens. Agora vamos partir para o arrebento.

LICENÇAS

 Neste primeiro tópico eu analiso quais as licenças adotadas por cada implementação levando em conta que cada licença proporciona vantagens e desvantagens. Parece um assunto irrelevante, mas trata-se de algo que pode afetar fortemente todo o mercado, todo um ecossistema e automaticamente você (se hoje o busybox estivesse sob GPLv3, provavelmente você nem teria um roteador em sua casa).

Licenças adotadas por cada implementação do comando

 Enquanto o gnu-sed está sob GPLv3+, o busybox-sed manteve-se sob GPLv2 mesmo tendo originado-se do gnu-sed (como pode ser lido no artigo O Paradoxo do Navio de Teseu no mundo open source) e é mantido pelo FFC.

Passe o cursos sobre a imagem para ler a tradução (texto original, basta clicar aqui)

 O sbase e o 9base estão sob MIT (9base sob MIT/X Consortium License); o minised foi disponibilizado sob GPL a partir da versão 1.13 e passou a ser disponibilizado sob BSD-like a partir da versão 1.14 em diante com o consentimento de Eric Raymond. O toybox está sob a clausula zero BSD (0-BSD) criada por Rob Landley que na verdade trata-se de uma Domínio Publico apenas sob o nome de BSD (com a aprovação dos próprios membros dos BSDs).

 VENCEDOR: Com exceção da GPL (que possui tendência natural a declínio), todos as demais licenças são muito boas. O busybox_SED ainda pode levar alguma vantagem com a GPLv2 por não ser incompatível com o kernel Linux e ser menos negativamente impactante que a GPLv3.

TAMANHO DOS BINÁRIOS

 Tenha em mente que, quanto menor o binário, melhor é em todos os sentidos (segurança, desempenho, modularidade e portabilidade). Códigos menores se tornam mais fáceis de manter e serem atualizados.

Passe o cursor sobre a imagem para ler a tradução

 Como mencionado no site do projeto embutils (que infelizmente não entrou para nossa lista), o userland dos Unix geralmente é composto de comandos dos BSDs e do projeto gnu. Na época que surgiram, as técnicas de desenvolvimento eram diferentes; os projetos focavam somente em recurso, mas não na otimização do tamanho.

Passe o cursor sobre a imagem para ler a tradução

 No episódio 06 do Linux Link Radio Rob Landley menciona que na época em que era mantenedor do BusyBox curiosamente descobriu que foram  escritas 833 linhas de código apenas para implementar o comando cat... E parece que não mudou muita coisa já que o gnu cat hoje ele possui 805 linhas... Outra coisa bem curiosa relatada por Rob é que, um simples código "hello World" linkado estaticamente à glibc, gera um binário de 400k.... Desenvolvedores de embarcados são declaradamente inimigos mortais da glibc.

 Para dispositivos como embarcados e até mesmo para o processo de boot, binários grandes são simplesmente inviáveis e parece não fazer sentido, mas mesmo em ambientes como desktop, servidores e até supercomputadores binários menores também são extremamente importantes pois assim o sistema consegue melhor desempenho em seus processos, é carregado mais rápido pela  cache L2, deixa o buffer mais livre.

 Há ressalvas a serem consideradas durante as avaliações como sua ligação se dinâmica ou estática, quais bibliotecas foram utilizadas, qual compilador e com quais flags e assim por diante. As ressalvas foram feitas em asteriscos (*).

Tamanho de cada implementação do comandos sed.

*Relembrando aqui que menor significa melhor

**Eu compilei o minised estaticamente a dietlibc.

***Consta no site do busybox que o busybox_SED possui 89K; porém, após baixar, seu tamanho final é de 92K (também likado estaticamente. Baixe aqui para conferir).

**** Eu compilei o sed do toybox dinamicamente para que pudéssemos saber o seu real tamanho.

 VENCEDOR: Neste caso eu deixo três colocados. O toybox sed em primeiro com apenas 36k; o minised em segundo com apenas 44k, e o sbase sed em terceiro com 56K.

Comparação de tamanhos entre minised linkado estaticamente e toybox sed linkado dinamicamente

 Você deve estar se perguntando se não seria injusto sendo que o toybox foi ligado dinamicamente enquanto quer o minised estaticamente. E a resposta é que o minised, mesmo ligado dinamicamente, é maior do que toybox sed. Confiram os resultados na imagem abaixo.

Comparação de tamanhos entre minised linkado tanto dinamicamente quanto estaticamente

 Além do mais, eu testei as versões binárias do toybox já disponibilizadas pelo próprio projeto que são linkadas estaticamente, e os comandos estão incorporados ao terminal (sendo um deles o sed). Mesmo contendo 231 comandos incorporados a si, o toybox  0.8.7 possui apenas 716K.

Reparem a quantidade de comandos dentro do toybox 0.8.7 em apenas 716k (sendo um deles, o comando sed que está selecionado nesta imagem).

RECURSOS

 É agora que constataremos se o tamanho dos binários fazem jus à quantidade de recursos. Reforçando o que foi dito no tópico anterior, quanto menor o binário, melhor é porém, não vai adiantar muito o binário ser pequeno e enxuto se não conter os recursos necessários para a sua adoção.

 Além do mais, esse é um ponto extremamente importante pois uma regra histórica que não falha é que, mesmo que um programa contenha certos bugs, mas possui os recursos que as pessoas querem (ou precisam), elas aceitam conviver com tais bugs. Tudo uma questão de prós e contras; além do que os bugs podem ser corrigidos ao longo do tempo (ou não, vai saber a complexidade).

 Podemos dizer que neste tópico o gnu-sed dispensa explicações pois um ponto forte das ferramentas do gnu (não por total mérito seu) mas que é mal divulgado pelo próprio projeto é exatamente a parte de recursos possuindo até mesmo extensões próprias. OK para o gnu-sed.

 No arquivo BUG do minised é descrito "Focarão nas conformidades POSIX e pequeno tamanho - extensões do GNU sed provavelmente não serão aceitas". O minised possui um diretório chamado tests que após compilá-lo, podemos executar o script run, conforme descrito em seu arquivo Makefile (cd tests; ./run ../minised) ou bastando executar o comando make check que se encarregará de fazer esse trabalho (realizando o total de 68 testes). Um dos testes falha (especificamente o empty-lhs), mas como descrito no próprio resultado, essa falha é intencional.

Testes disponibilizados pelo próprio minised

 O toybox também disponibiliza seus próprios arquivos de teste também dentro do diretório tests. No total, ele realiza 91 testes com o toybox sed.

Teste disponibilizados pelo próprio toybox

 O toybox sed possui uma lista dentro do seu próprio código fonte com algumas pequenas pendências a serem ajustados como "fazer y// lidar com delimitadores unicode, lidar com retorno de erro a partir do emit(), error_msg/exit consistentemente", "Qual a coisa certa a se fazer com -i quando escrever as falhas? Skip ou next?". Eu considero uma lista baixa; lógico que prefiro ver estas questões sanadas, mas são consideráveis.

O Busybox sed também possui uma pequena lista comentada em seu código fonte de apenas três de pequenos detalhes a serem acertados. 

 Eu não encontrei algumas pendências tanto no sbase quanto no 9base e não foram ruim nos testes.

 VENCEDOR: Empate geral. Em todos os testes que eu realizei, todas as implementações conseguiram processar com sucesso.

DESCRIÇÃO DE AJUDA

 Descrições de ajuda (--help e manpages) assim como as licenças, parecem ser irrelevantes, porém pense no seguinte cenário; você está administrando o seu sistema, precisa consultar uma opção e sabe que tal comando não possui opção de ajuda. Até aí, tudo bem, basta consultar a manpage... Certo?...

 A resposta é... depende de qual distribuição estamos falando. Distribuições como Alpine Linux ou Porteus não possuem manpages por padrão. E se de repente você não possui acesso a internet? O que você faz?...

Por que eu não tenho man pages ou cadê o comando 'man'?

 Do que adiante um programa conter todos os recursos necessários sendo que não vem com as informações de como utilizá-los? Seria o mesmo que uma TV não acompanhar manual de instruções. Alias, eu já vi empresas adotarem uma certa distribuição devido a facilidade em encontrar informações e soluções de problemas. Então, por mais que pareça algo irrelevante, descrições de ajuda é algo extremamente importante.

 E aqui vamos nós para a nossa analise. O minised, apesar de possuir uma boa manpage, não possui a opção --help por padrão. Eu acredito que poderia possuir ao menos uma leve descrição assim no sbase e no 9base. Ou melhor, assim como o busybox_SED; enxuta e explicativa.

Descrição de ajuda do minised e do sbase sed

Me lembra muito a descrição no Solaris

descrição de ajuda do busybox sed

 O gnu-sed e o toybox sed são os que melhores implementam tais descrições. Aqui eu postei apenas uma porção de toda a descrição de ambos.

Descrição de ajuda do gnu-sed

Descrição de ajuda do toybox sed

[27/11/2023] Estranhamente na versão 0.8.10 do toybox, a opção --help ficou bem limitada assim como da implementação do sbase e do Solaris. Porém, como já mostrado tanto aqui no blog quanto no canal, o toybox possui a opção help seguido do comando. Então, digitando toybox help sed, o comando sed do toybox oferece opções muito mais completa.

opção help do terminal de comandos toybox

VENCEDOR: Empate entre o toybox sed e o gnu-sed

POSSÍVEIS BUGS

 Já que falamos de recursos, agora vamos tratar de... bugs. O que é uma parte um pouco complicada de se tratar já que difícil constatar a real quantidade de bugs de um programa. Como todos sabem, há relatos de bugs que só foram encontrados mais uma década após sua existência. O bug estava lá mas só foi detectado dois de tanto tempo.

 Então, o que podemos fazer aqui é relatar os que já estão reportados em bug reports, procurar por informações em man pages, comentários dentro dos códigos, informações nos arquivos README e BUGS ou... da forma mais árdua, testando mesmo assim como já mostrei alguns que reportei e podem ser conferidos no meu canal clicando aqui. O que alias não é o meu interesse.

 Por exemplo, no arquivo BUGS do minised é descrito como não havendo a necessidade de regressão até o momento; porém, como puderam acompanhar no inicio, vale ressaltar que sua base de código é bem pequena (o que é muito vantajoso). Apesar disso, eu encontrei apenas dois comentários de FIXME nos códigos sedcomp.c e sedexec.c (/* FIXME: scan for the brace end */ e /* FIXME: lastep becomes start */).

 O mesmo ocorre no toybox sed (tendo sua base de código ainda menor que do minised). A primeira versão do sed no toybox surgiu na versão 0.5.1 (em Novembro de 2014). De lá para cá, poucos bugs foram encontrados (total de 11 bugs encontrados e corrigidos desde então. Um deles pode ser conferido clicando aqui) e poucos deles eram críticos. O minised teve 12 correções desde a versão 1.3 que podem ser lidos em seu README.

 E que comece o choro e ranger de dentes. O gnu-sed é o que mais podemos encontrar bugs. Em seu próprio git (clicando aqui) ou podem ser conferidos no Debian Bugs clicando aqui apresentam uma lista de bugs conhecidos.

 Já o Busybox_SED possui apenas duas informações de FIXME em seu código mas é possível consultar bugs em seu próprio bug reports clicando aqui.

 No código do sbase sed existem 20 comentários com o dizer FIXME. Estes comentários descrevem correcções que ainda são necessárias. Foi difícil encontrar algo relacionado ao 9base sed, há sim correções ocorrendo e podem ser conferidas no próprio git do plan9port (clicando aqui), mas não é uma lista fácil de encontrar (muito menos especificamente de seu sed).

 VENCEDOR:  Com excessão do gnu-sed, todos os demais apresentaram baixa quantidade de bugs.

DESEMPENHO

 E por fim, a parte que a galera vai para delírio: benchmarks... Parece que a galera pira com essa palavra. Aqui eu considerei analisar tanto o uso de CPU quanto o tempo para a concluir as operações. E obtivemos os seguintes resultados:

 Estranhamente tanto o gnu-sed, o sbase sed, o 9base sed e o busybox_SED se comportam da mesma forma. eles sempre se mantêm na margem de 86-89% de uso de CPU, nunca a menos nem a mais do que isso. Mas não devemos analisar unicamente o uso de CPU pois, de certo forma, isso pode significar tanto algo bom quanto algo ruim; tudo vai depender muito da situação.

 Reparem um exemplo disso na imagem abaixo onde fiz uma analise entre o minised e o gnu-sed sendo eles separados pela faixa azul. Enquanto o gnu-sed manteve o uso de 89% de CPU, o minised desta vez fez uso de 106%. Apesar do uso de CPU do minised ter sido mais alto, o mimised concluiu sua operação em 120ms enquanto que o gnu-sed concluiu a mesma operação em 284ms.

Comparação de uso de CPU e tempo de conclusão entre minised e gnu-sed

 Para que o gnu-sed, sbase sed, 9base sed e o busybox_SED consigam concluir as operações no mesmo tempo que o minised, seria necessário que utilizassem entre 136,17% a 161,87% a mais de CPU além dos 89% já utilizado. O que totalizaria entre 225,17% a 250,87% de uso de CPU.

 VENCEDOR: Empate entre o minised (utilizando entre 61% - 76% de CPU porém, com menor tempo de execução) e toybox sed (utilizando entre 50% - 76% de CPU, algumas vezes atingindo 88%). Os demais ficam entre 86% a 89% de uso de CPU e o mesmo tempo de execução.

CONCLUSÃO

 O primeiro lugar fica para o toybox sed com 6 pontos. O minised em segundo com 5 pontos perdendo apenas na descrição de ajuda apesar que possui uma boa manpage. Então poderíamos declarar empate entre os dois já que o minised possui desempenho melhor do que o toybox sed.

 O segundo lugar ficaria empatado entre o busybox_SED com quatro ponto (tamanho, recursos, descrição de ajuda e poucos bugs) e o sbase sed (licença, tamanho, recursos e poucos bugs). O 9base sed teve três pontos (licença, recursos e bugs) e o gnu-sed apenas dois pontos (recursos e descrição de ajuda).

Conclusão da analise das implementações do sed

Existem outras implementações ou comandos semelhantes como é o caso do comando sd , mas não nos interessa para este artigo.

sd é um comando que pode substituir find, sed e awk.

Adquira também o Definitive Guide to sed: Tutorial and Reference

Leia também o artigo "Bug no terminal de comandos Bash e comparação entre os pacotes de coleções de comandos"

minised: Um sed melhor do que o sed

Sed do Aurélio

página oficinal do sed do GNU

Manual sed do GNU (vale muito a pena a leitura).

Código fonte do minised hospedado na exactcode.com

Busybox sed

QUER APRENDER LINUX DE VERDADE? ENTÃO VENHA APRENDER COMIGO ;)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte