Procura-se, Vivo ou Morto: editor CLI
Este artigo baseia-se fortemente na página Wanted: Console Text Editor for Windows, que é muito completa e que recomendo fortemente que leiam (de caminho, ponham uma estrela no perfil GitHub do autor, Antoni Sawicki); no entanto, descobri tantas coisas que decidi que talvez possa dar a minha achega.
O artigo original começa com as minhas razões para investigar este assunto:
Since 2012 or so Microsoft is pushing concept of running Windows Server headless without GUI and administering everything through PowerShell. I remember sitting through countless TechEd / Ignite sessions year after year and all I could see were blue PowerShell command prompts everywhere. No more wizards and forms, MMC and GUI based administration is suddenly thing of a past. Just take a look at Server Core, WinPE, Nano, PS Remoting, Windows SSH server, Recovery Console and Emergency Management Services. Even System Center is a front end for PowerShell. Nowadays everything seems to be text mode.
This overall is good news and great improvement since previous generations of Windows, but what if you need to create or edit a PowerShell, CMD script or some config file?
Desde 2012, mais coisa menos coisa, que a Microsoft está a promover a ideia de correr o Windows Server headless (sem GUI) e administrar tudo por PowerShell. Lembro-me de assistir a incontáveis sessões TechEd/Ignite ano após ano e eram sessões azuis PowerShell até perder de vista. Nada de wizards nem de formulários; MMC e administração por GUI passaram de repente a ser coisas do passado. Basta pensar em Server Core, WinPE, Nano, PS Remoting, Windows SSH, Recovery Console e Emergency Management Service. Até o System Center é uma fachada bonita em cima de PowerShell. Hoje em dia tudo parece ser em modo texto.
Em geral, são boas notícias e uma grande evolução sobre versões anteriores do Windows, mas e se precisarmos de criar ou editar scripts PowerShell ou CMD, ou mesmo um ficheiro de configuração?
Exactamente!
A primeira vez que me dei conta desta necessidade foi quando precisei de editar um ficheiro de configuração de um pacote portado do *NIX - o Notepad nem sequer suportava quebras de linha UNIX, por isso tive de instalar o Notepad++, e nada contra este último, excelente programa que só é pena que não seja multiplataforma - mas fiquei a pensar:
E se só tivesse acesso remoto por CLI?
E sim, nos Windows (cliente) mais modernos existe o Windows Subsystem for Linux (WSL), com acesso directo aos sistemas de ficheiros nativos do Windows, mas também toda a panóplia de shells e utilitários para *NIX. Mas não há WSL no Windows Server…
Parâmetros de avaliação
Tenho alguns critérios que me ajudaram a eliminar uma quantidade substancial de candidatos:
- Uso livre e/ou gratuito, mesmo em utilização profissional
- Compatível com x64
- Suportar terminações de linha *NIX e DOS
- Suportar UTF-8
- Poder correr de um executável com um mínimo de instalação (sobretudo, nada de espalhar 400 ficheiros pelo disco de sistema)
Sistema testado
Os editores foram testados sumariamente em Windows 10, mas as instalações documentadas neste artigo são em Windows Server Core 2022 (se bem que para Server 2019 não deve haver grande diferença).
Editor simples
Este tipo de editores tem funcionalidades muito básicas, especialmente de busca e substituição, e raramente oferecem coisas como formatação de sintaxe; são para abrir um ficheiro de texto, mudar duas linhas e fechar. No mundo DOS/Windows, seguem o standard de interface CUA (Common User Access), desenvolvido para o OS/2 e utilizado em todas as aplicações da Microsoft, nomeadamente o EDIT.COM que foi lançado no MS-DOS 5.
EDIT.EXE
Este último é o mesmo EDIT.EXE que ainda está disponível em algumas versões do Windows. Só que como se trata de um programa de 16-bits, só corre em versões x86 de Windows. Testei com a versão 20H02, que ainda existe em x86, mas os Windows 10 OEM deixaram de ter versão x86 desde a 20H01, também conhecida como 2004.
Antes de tentar correr o comando, é necessário ir às Properties da janela do CMD.EXE, separador Options e activar o Legacy Console; depois fechar o CMD.EXE e voltar a abrir.
Quando se tenta correr o executável pela primeira vez, o Windows pede para instalar uma biblioteca, NTVDM, que é a NT Virtual DOS Machine.
Depois de cumpridos estes requisitos, conseguimos abrir o velhinho MS-DOS Editor - claro que não funciona em x64, não sabe o que são terminações *NIX e nem imagina o que é UTF-8, por isso é apenas uma curiosidade…
A última versão de Windows Server com suporte x86 é o Windows Server 2008, baseado no Vista.
YEdit
O YEdit faz parte do conjunto de utilitários de shell Yori
É possível correr o YEdit sem o Yori, mas primeiro é preciso descarregar o Yori, como vou mostrar.
O instalador do Yori é apenas um stub que descarrega a última versão directamente do repositório; ora, apesar de isso ser uma boa ideia (o instalador é sempre o mesmo e não é preciso reconstruí-lo a cada nova versão), esse modo de funcionamento, acrescentado ao facto de o instalador não estar assinado, faz com que todas as protecções anti-malware sejam activadas (avisos dentro do browser, SmartScreen, Windows Defender, etc.) se estivermos num Windows cliente; mas quando logados como Administrator num Windows Server, nada disto acontece.
É compatível com x64 e UTF-8, que é o mais importante, mas é possível definir uma code page específica (lembram-se?) para abrir aqueles ficheiros que ficaram no século passado.
Para mais informação sobre o Yedit, o mesmo autor do artigo original em que me estou a basear fez um artigo especificamente sobre o Yedit: Yedit – The missing edit.com replacement for modern Windows
Pela minha parte, depois de ultrapassada a questão da instalação, corre em Windows x64 e suporta UTF-8, por isso está aprovado…
Instalação
Para ficarem acessíveis, estes editores podem ser copiados para uma pasta do perfil local do utilizador como %LOCALAPPDATA%\Microsoft\WindowsApps\
; esta pasta é usada pela Microsoft para deixar atalhos para a localização real de vários executáveis como o winget
, Windows Terminal (wt.exe
), Edge, etc.
Não existe Microsoft Store nos Windows Server mas a pasta existe na mesma e faz parte da variável PATH.
Descarregamos o instalador:
|
|
E instalamos directamente:
|
|
Obtaining package URLs... Installing 1 of 4: http://www.malsmith.net/download/?obj=yori/latest-stable/yori-ypm-amd64.cab Installing 2 of 4: http://www.malsmith.net/download/?obj=yori/latest-stable/yori-core-amd64.cab Installing 3 of 4: http://www.malsmith.net/download/?obj=yori/latest-stable/yori-typical-amd64.cab Installing 4 of 4: http://www.malsmith.net/download/?obj=yori/latest-stable/yori-completion-noarch.cab Applying installation options... Installation complete. Success: Installation complete.
Apesar de $ENV:LocalAppData\Microsoft\WindowsApps\
fazer parte do PATH privado de cada utilizador desde o Windows 8, as suas subpastas não fazem (e teria sido feio largar o Yori na raiz da pasta); por isso, temos de acrescentar ao PATH o caminho onde instalamos o Yori:
|
|
E finalmente yedit
Por sua vez, o yedit.exe
pode ser usado sozinho, sem o Yori, depois do mesmo ser instalado; nesse caso, convém não acrescentar a pasta do Yori ao PATH)
|
|
Para facilitar a vida ao leitor, vou disponibilizar aqui no site o executável do YEdit 1.70; usando este executável, basta largá-lo em $ENV:LocalAppData\Microsoft\WindowsApps\
ou outra pasta que faça parte do PATH.
yedit.exe v1.70 - (c) Malcolm Smith
Mas uma vez mais, recomendo que experimentem e utilizem todo o pacote do Yori, porque vale a pena.
Sobre o Yori
Um comentário quanto ao Yori: não sei onde é que o Yori esteve a minha vida toda, mas é fantástico. É o que o CMD.EXE devia ser há 20 anos, e é uma excelente opção se desejam uma shell mais poderosa sem ter de migrar para PowerShell ou instalar 1GB de WSL só para ter acesso às shells do mundo *NIX. Deixo uma pequena amostra dos comandos suportados:
Wishlist: Tilde
No mundo *NIX aconteceu o oposto, que foi alguém ter desenvolvido um editor simples com a interface CUA típica do Windows, que é mais natural para quem transita de uma GUI para a CLI. Esse editor chama-se Tilde e de momento não tem versão para Windows.
Seria bom ter duas opções…
Editor avançado
Estes editores são mais poderosos e têm uma curva de aprendizagem mais inclinada que os editores mais simples como o Notepad:
Mas costumam ter funções avançadas como macros, múltiplas janelas, coloração de sintaxe, plugins, etc.
Começando pelos editores clássicos do *NIX: Pico (Nano), VI (VIm), JOE e EMACS :
Pico/Nano: 404
A fonte mais próxima do Pico (o editor do programa de email Pine, daí o nome - PIne COmposer) deveria ser o site oficial, mas há muito tempo que é abandonware, desde que a universidade que o criou se esqueceu dele.
Não só não é actualizado para MS-DOS desde 1997, como necessitava da instalação do middleware DJGPP. Outros tempos…
Já o clone da FSF, GNU Nano, não oferece um ficheiro binário para Windows, e a compilação independente mais popular exige a instalação da biblioteca Cygwin para simular um ambiente POSIX no Windows; um pouco pesado de mais para o que estou à procura.
Micro
No entanto, um outro clone do Pico, chamado Micro, pode ser uma boa aposta:
É o mais recente de todos, ainda está em desenvolvimento, é escrito em Go e tem versões para OSX, Free/Open/Net BSD, Linux (x86, x64 e ARM), e Windows (x86 e x64).
Funciona bem, tem uma command bar (Ctrl-E
) e os atalhos baseiam-se na tecla Ctrl
seguindo a linha familiar do Pico, Nano, etc.
Tal como queremos para este desafio, o “instalador” é apenas um ZIP com um executável estaticamente linkado.
Instalação
|
|
O ficheiro de configuração do Micro fica em $ENV:UserProfile\.config\micro\settings.json
VIM
A versão para Microsoft do VIM (Vi, IMproved) vem em várias declinações (incluindo uma versão com interface gráfica chamada gvim
), mas o que nos interessa é o executável para consola, que é compilado para x86 - mas não vamos abrir ficheiros com mais de 2GB, correcto?
Caso precise mesmo de abrir ficheiros com mais de 2GB, o Neovim existe em versão x64 e instala-se mais ou menos da mesma maneira que se segue.
Instalação
O processo de descarregar e “instalar” é muito similar ao que foi usado para o Micro:
|
|
O perfil do Vim fica em $ENV:UserProfile\.vimrc
.
Podem ver uma sugestão de .vimrc
na página DotFiles
JOE (Joe’s Own Editor)
O JOE é bastante menos conhecido, mas tem os seus fãs.
Para mais informações sobre o JOE para Windows, veja esta página.
Felizmente, existe como executável independente, e até em várias versões consoante a interface preferida:
- joe para quem respeita o original
- jmacs para quem gosta de EMACS
- jstar para quem prefere Wordstar
- jpico para quem tem saudades do Pico/Nano e não gosta de mexer numa configuração em JSON como a que é usada pelo Micro
Infelizmente, por estarem alojados no SourceForge, não encontrei nenhum link directo que permitisse descarregar os ficheiros numa instalação-base Windows Server Core; mas num WinServer com Desktop Experience, pode usar um browser para instalar e usar o JOE.
Num Windows Server Core, é necessário instalar o programa WGET
WGET para Windows
O comando Invoke-WebRequest
num Windows Server Core não pode recorrer ao motor de páginas HTML do sistema (Trident ou Blink) para pedidos HTTP complexos, como estes endereços do SourceForge que incluem redirects. Mas um utilitário de linha de comando que o pode fazer é o GNU WGET, que uma alma caridosa compila e distribui para Windows
Instalamos o WGET com o mesmo método básico:
|
|
wget
, por defeito, é um Alias para Invoke-WebRequest
, por isso é necessário chamar o executável WGET com wget.exe
ou desactivar o Alias; em PowerShell 6+ é simples porque existe o comando Remove-Alias
, mas em Windows PowerShell (a versão que vem por defeito nos sistemas Windows, que corresponde ao PowerShell 5.1), é um pouco mais complexo porque o comando não existe e os Alias têm vários Scopes em PowerShell. No entanto,
while (Test-Path Alias:wget) {Remove-Item Alias:wget}
resolve o problema.
wget.exe -h
, ou wget -h
se tiver seguido a recomendação acima:
Descarregar o JOE com o wget e instalar
|
|
Como se vê, o JOE abre uma nova janela em vez de utilizar a janela actual, por isso precisa de ser testado se funcionará numa shell remota pura como SSH ou PSRemoting e não numa sessão RDC.
Testar com OpenSSH
No Windows Server (2022 ou 2019), correr os comandos:
|
|
Name : OpenSSH.Client\~\~\~\~0.0.1.0 State : Installed Name : OpenSSH.Server\~\~\~\~0.0.1.0 State : NotPresent
O cliente SSH está instalado, por isso instalamos o OpenSSH.Server seguindo as instruções da Microsoft:
|
|
Como já temos o cliente SSH instalado, podemos abrir uma sessão SSH directamente no localhost
:
|
|
The authenticity of host 'localhost (::1)' can't be established. ECDSA key fingerprint is SHA256:[…]. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. Administrator@localhost's password: Microsoft Windows [Version 10.0.20348.350] (c) Microsoft Corporation. All rights reserved. administrator@WIN-L32NQRNJ5GI C:\Users\Administrator>
E como suspeitava, tentando abrir o joe
numa sessão CLI pura, não abre.
Por isso, uma vez que para usar o JOE é necessário estar numa sessão Remote Desktop, na minha opinião mais vale usar o Notepad++
O YEdit, o Micro e o Vim abrem correctamente dentro da sessão SSH.
EMACS
Se quiser mesmo usar o EMACS para editar uns ficheiros de texto, posso sugerir o JOE com interface EMACS (jmacs
)?
Não?
Então a melhor página que encontrei que o pode ajudar está aqui.
Citando o artigo original,
Emacs.exe binary is whopping 83 MB in size and the zip file contains two of them just in case. Whole unpacked folder is 400 MB.
Eu mencionei que estava à procura de soluções pequenas e práticas, não de um sistema operativo e linguagem de programação que por acaso inclui um editor de texto ¯\(ツ)/¯
Menções honrosas
O artigo original mencionava muito mais editores, mas experimentei a maior parte e acabei por abandonar quase todos porque eram impraticáveis ou incompatíveis.
Dos que me pareceram possíveis e que testei, apenas vou comentar as minhas impressões depois de os instalar; como não os acho úteis para os dias de hoje (por exemplo, por não suportarem UTF-8), não vou documentar a sua instalação.
Open Watcom VI
https://github.com/open-watcom/open-watcom-v2
https://github.com/tenox7/ntutils/tree/master/owvi
O autor do artigo original deu-se ao trabalho de compilar apenas o editor do pacote OpenWatcom, que se instala a partir de https://github.com/tenox7/ntutils/blob/master/owvi/vi-x64.exe ou https://github.com/tenox7/ntutils/blob/master/owvi/vi-x86.exe; a documentação está em https://github.com/tenox7/ntutils/blob/master/owvi/vi.pdf
No entanto, apesar de parecer um bom compromisso entre o VI e um editor com menus (pode-se usar tal e qual como o VI, parece compatível com .vimrc
, mas tem menus), não suporta UTF-8.
Kinesics Text Editor
https://turtlewar.org/projects/editor/
https://turtlewar.org/projects/editor/kit-153-win.exe
Funciona em várias plataformas, mas o instalador Windows só funciona com permissões de Administrador, o que imediatamente nos avisa que é um programa de outros tempos…
É extremamente configurável, tem funcionalidades avançadas como selecção em modo de coluna (vi Visual Mode) mas também não suporta UTF-8
E não é actualizado desde 2015
FTE Editor
http://fte.sourceforge.net/
https://github.com/tenox7/ntutils/tree/master/fte
Não corre porque precisa de bibliotecas MSVC muito antigas que não estão disponíveis num sistema Windows moderno
Thomson-Davis Editor - TDE
http://adoxa.altervista.org/tde/
https://github.com/tenox7/ntutils/tree/master/tde
A profundidade dos menus e atalhos é enorme, é um editor extremamente poderoso, mas também não suporta UTF-8…
Conclusão
Depois de décadas a promover a gestão de sistemas por interfaces GUI, os editores CLI nativos das plataformas Microsoft definharam ao ponto de não terem salvação. O único que ainda é viável é o YEdit, talvez porque o programador ainda não desistiu (e parece um programador do caraças); além disso, o YEdit é muito simples.
Mas mesmo o fantástico Yori não teria sucesso onde o Cscript e o Kermit não tiveram (este Kermit era uma adaptação da Korn shell para Windows que a Microsoft pensou em desenvolver), porque o problema advinha de a CLI não ter interfaces consistentes com as quais interagir num sistema que depende completamente de interfaces como o Windows; isso só apareceu com o PowerShell e as ideias que lhe estão por trás.
As melhores opções acabam por ser os editores vindos do *NIX que se mantiveram actualizados e que têm versões para Windows.
Caso a falta de suporte a UTF-8 não seja um problema, gostei bastante do OpenWatcom VI e do TDE.
Mas as minhas escolhas são, claramente, o YEdit para coisas muito rápidas e o Vim para tarefas mais complicadas.
Boa sorte!