Pode haver algum problema ao usar o gedit para editar arquivos do sistema com 'sudo -H gedit'?

Eu sou relativamente novo no Ubuntu, notei que nas respostas deste site, quando as pessoas sugerem editar arquivos do sistema, o comando que dão é sempre sudo nanoou sudo vi. Como não gosto de usar editores de texto baseados em terminal, geralmente uso

sudo -H gedit

em vez disso, e até agora funcionou perfeitamente bem.

Pode haver algum problema com o uso geditpara editar arquivos do sistema ou a escolha do editor de texto depende exclusivamente da preferência da pessoa? Há algo que eu deva ter em mente (como codificação) ao editar esses arquivos?

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 nanoe vimgeralmente é recomendado. Os editores de texto baseados em terminal, como vim(ou pelo menos um vicomando), nanoestã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. vimPoré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, sudoeditusa 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, VISUALou EDITOR variáveis de ambiente , que ele consulta nessa ordem. Assim, você pode executar:

VISUAL=gedit sudoedit filename

Substitua filenamepor 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, sudoeditverifica se você realmente fez alterações. Se você fez isso, ele copia a cópia temporária modificada de volta ao original.

Enquanto sudoedittrabalha 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 sudoeditvocê 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/filenamedeve 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 gvimcomando) ou não graficamente (o vimcomando). 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 nanoe sudo vimexecutam esses editores como root, mas $HOMEainda 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 -iou -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 nanoe 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 vimconfiguraçã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 filenamesudo vim filenameVISUAL=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 vimtêm um pouco do mesmo problema que o comando (desaconselhado!) sudo gedit. Se você executar um editor como vimcomo root, mas sem reiniciar $HOME(como sudo -He sudo -ifaria), 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 sudoeditou, na área de trabalho, iniciando o editor normalmente, mas acessando o arquivo por um admin://caminho.

Finalmente, observe que o comportamento acima mencionado de sudoquando -Hou -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.

Para responder à sua pergunta: Em geral, o uso de um editor de GUI não será um problema, além de geditser muito lento para arquivos grandes.

Mas para programas GUI você usaria pkexecou em gksuvez de sudo. Pode ser necessário configurarpkexec antes que funcione.

pkexec gedit

ou para versões mais antigas do Ubuntu (por exemplo, 16.04), você pode usar:

gksu gedit

(Embora você possa tentar melhores editores de GUI, por exemplo geany;-))