Desde que você o execute corretamente, é uma questão de sua preferência.
Além das diferenças nos recursos , qual editor de texto você usa é de fato a sua preferência. Isso é verdade mesmo quando o seu editor de texto é um programa gráfico como o Gedit . Isso não quer dizer que não haja uma boa razão nano
e vim
geralmente é recomendado. Os editores de texto baseados em terminal, como vim
(ou pelo menos um vi
comando), nano
estão disponíveis mesmo quando não há GUI e até na maioria dos sistemas mínimos e com falhas ; eles têm alguma tradição por trás deles (se você é parcial com esse tipo de coisa); eles podem ser executados no mesmo terminal em que outras tarefas são executadas; eles se integram automaticamente aos fluxos de trabalho dos usuários do multiplexador de terminal ; e é mais provável que estejam disponíveis do que qualquer outroeditor de texto gráfico em particular , mesmo o Gedit, mesmo no Ubuntu (que possui vários sabores ).
Isso não é tudo. Se você estiver editando arquivos do sistema, uma abordagem é executar seu editor como root. Essa não é a única abordagem, e existem alguns argumentos contra ela (veja abaixo), mas é comum. Se você tomar essa abordagem e usar um programa gráfico como seu editor, então você precisa cuidar para executá-lo de tal forma que $HOME
é o diretório home do root ao invés de seu próprio , e isso acrescenta outra camada de confusão e complexidade. Mas você já está fazendo isso; você está correndo sudo -H gedit
, que é uma das maneiras razoáveis . Ainda assim, essa complexidade é outra razão pela qual as pessoas tendem a sugerir editores não gráficos.
Programas gráficos são geralmente mais complicados do que programas não gráficos. Ter mais coisas rodando como root geralmente é ruim, pois há mais maneiras de as coisas darem errado, inclusive devido a possíveis erros, inclusive por acidente. vim
Porém, os editores de texto não gráficos, como também são bastante sofisticados, e geralmente são configurados para executar vários programas externos para executar várias tarefas.)
Além de executar o editor como root, outra abordagem geral é editar um arquivo que o editor pode modificar, mesmo quando executado como usuário (não root), de modo que as alterações no arquivo sejam propagadas para o arquivo de propriedade raiz que você deseja mudar. Isso soa abstrato porque as especificidades variam consideravelmente. Duas grandes abordagens concretas seguem.
sudoedit
Uma maneira bastante antiga de fazer isso é sudoedit
(documentada na mesma página de manual quesudo
). Por padrão, sudoedit
usa o editor de texto padrão , que geralmente não é - e não deve ser - um programa gráfico. Mas você pode dizer-se usar qualquer editor através dos SUDO_EDITOR
, VISUAL
ou EDITOR
variáveis de ambiente , que ele consulta nessa ordem. Assim, você pode executar:
VISUAL=gedit sudoedit filename
Substitua filename
por um caminho relativo ou absoluto para o seu arquivo.
Isso faz uma cópia temporária do arquivo que você deseja editar. A cópia pertence a você, não à raiz (ou a quem seja o proprietário original). Ele abre o editor de texto e você pode editar a cópia temporária. Quando você fecha o editor de texto, sudoedit
verifica se você realmente fez alterações. Se você fez isso, ele copia a cópia temporária modificada de volta ao original.
Enquanto sudoedit
trabalha com editores gráficos, também é útil para editores baseados em terminal. Em ambos os casos, o editor de texto funciona como você, por isso tem sua configuração, e outras ações que você executar nele outra do que as modificações feitas para esse arquivo são realizadas por você, que oferece um pouco de proteção contra alguns tipos de erros.
Você pode definir uma dessas variáveis de ambiente persistentemente, se quiser. SUDO_EDITOR
é talvez o melhor, pois é usado para menos outras coisas. No entanto, se você configurá-lo como gedit
, lembre-se de que comandos como não funcionarão quando nenhuma GUI estiver disponível, como costuma acontecer (embora nem sempre ) em um console virtual ou via SSH .sudoedit filename
O administrador do GVFS
Outra maneira mais recente de fazer isso é abrir o arquivo através do admin://
caminho GVFS, em vez do caminho tradicional no estilo Unix. Agradeço a pomsky por me ensinar sobre isso. Assim como existem caminhos GVFS para editar arquivos que, em outros aspectos, não são um local conveniente para serem editados - por exemplo, porque eles estão em uma máquina remota à qual você está conectado através do SSH - o GVFS suporta admin://
caminhos para editar arquivos você não possui.
Isso é conceitualmente semelhante ao de sudoedit
você executar o editor como você mesmo e o arquivo que o editor vê é algo que ele pode editar. Tentar abrir o arquivo requer que você se autentique; essa não é uma maneira mágica de contornar as restrições de segurança usuais.
gedit admin:///path/to/filename
Lá, /path/to/filename
deve ser um caminho absoluto para o arquivo, começando com /
. Portanto, existem três /
caracteres depois admin:
.
Codificações e outras coisas afetadas teoricamente pela configuração do editor
A codificação de um arquivo não é realmente afetada se o editor que você usa é ou não gráfico. Alguns editores, por exemplo vim
, podem operar graficamente (o gvim
comando) ou não graficamente (o vim
comando). A resposta simples para sua pergunta sobre codificações é que você não precisa se preocupar com isso. Isso é próximo o suficiente da verdade para que você realmente não precise ler o restante desta resposta.
Nas versões atuais (e anteriores) do Ubuntu, os comandos gostam sudo nano
e sudo vim
executam esses editores como root, mas $HOME
ainda configuram o seu diretório pessoal. Isso significa que os editores, por padrão, usam sua configuração em vez da configuração da raiz. Se houver algo na sua configuração desses editores (ou em um programa que eles executam para executar parte de seu trabalho, como git
) sobre codificações ou finais de linha , isso será seguido. Com isso não vai acontecer.sudo -H editor
Algumas pessoas usam nua sudo
(ou seja, sem -i
ou -H
) para os editores, porque eles querem isso. Mas, na verdade, você deve pensar duas vezes sobre isso. Não apenas você pode atingir esse objetivo de maneira mais limpa com um método como sudoedit
, como existem outras desvantagens de comandos como sudo nano
e sudo vim
:
Se a configuração do seu editor faz com que algo seja executado, ele é executado como root. Para editores sofisticados como vim
, isso pode fazer com que um pouco de código não trivial seja executado como root. Como mencionado acima, ter menos código executado como root geralmente é bom e esse é um dos argumentos contra a execução de editores gráficos como root.
Se a sua vim
configuração tem inúmeros plugins - por exemplo, para realizar uma análise estática no código-fonte enquanto você digita - e raiz de não acontecer, menos corridas coisas como root com que . (Ainda menos roda como root , mas seus plugins ainda funcionam!) Isso é separado se o seu editor é ou não gráfico.sudo -H vim filename
sudo vim filename
VISUAL=vim sudoedit filename
Se a configuração do seu editor estiver quebrada e impedir que você edite arquivos com facilidade, a correção pode ser ainda mais complicada, pois também se aplica à raiz. Isso é apenas um aborrecimento, não um problema difícil de resolver.
Comandos como sudo vim
têm um pouco do mesmo problema que o comando (desaconselhado!) sudo gedit
. Se você executar um editor como vim
como root, mas sem reiniciar $HOME
(como sudo -H
e sudo -i
faria), e cria arquivos de configuração por si só , esses arquivos de configuração irá residir em seu diretório home, mas eles vão ser propriedade de raiz, e sua configuração pode ser um pouco quebrado quando você executar o editor mais tarde.
Bem, isso com certeza parece muito com esse problema! A razão pela qual isso é menos importante do que com aplicativos gráficos é que o editor geralmente ainda é iniciado, as mensagens de erro geralmente são mais fáceis de entender, você geralmente pode descobrir quais arquivos específicos são afetados com muito mais facilidade, e a quebra normalmente está limitada a esse único programa. (Os programas gráficos usam arquivos de configuração em mais locais.) Além disso, diferentemente dos editores gráficos, os usuários que usam apenas casualmente um editor de texto e não alteram deliberadamente sua configuração têm pouca probabilidade de enfrentar esse problema.
Novamente, você pode usar a configuração do editor da sua própria conta de usuário e evitar problemas de permissões usando sudoedit
ou, na área de trabalho, iniciando o editor normalmente, mas acessando o arquivo por um admin://
caminho.
Finalmente, observe que o comportamento acima mencionado de sudo
quando -H
ou -i
é passado é realmente planejado para mudar em uma versão futura do Ubuntu (como já aconteceu, anos atrás, na maioria dos sistemas operacionais que usam Unix sudo
). O comportamento já mudou no Ubuntu 19.10 , que é a versão de desenvolvimento até o momento em que este artigo foi escrito.
-H
parte é importante , não usesudo
para iniciar aplicativos GUI sem ela.