Finché lo esegui correttamente, è una questione di tua preferenza.
A parte le differenze nelle funzionalità , quale editor di testo che usi è praticamente la tua preferenza. Questo è vero anche quando il tuo editor di testo è un programma grafico come Gedit . Questo non vuol dire che non ci sono buoni motivi nanoe vimsono spesso raccomandati. Gli editor di testo basati su terminali gradiscono vim(o almeno un vicomando) e nanosono disponibili anche quando non è presente la GUI e persino sui sistemi più minimali e rotti ; hanno delle tradizioni alle spalle (se sei parziale in quel genere di cose); possono essere eseguiti nello stesso terminale in cui vengono eseguite altre attività; si integrano automaticamente nei flussi di lavoro degli utenti del terminale multiplexer ; e hanno maggiori probabilità di essere disponibili di qualsiasi altroparticolare editor di testi grafici, anche Gedit, anche su Ubuntu (che ha diversi gusti ).
Non è tutto. Se hai intenzione di modificare i file di sistema, un approccio è quello di eseguire il tuo editor come root. Questo non è l'unico approccio e ci sono alcuni argomenti contro di esso (vedi sotto), ma è comune. Se adotti questo approccio e usi un programma grafico come editor, allora devi aver cura di eseguirlo in modo tale che $HOMEsia la home directory di root piuttosto che la tua , e questo aggiunge un altro livello di seccatura e complessità. Ma lo stai già facendo; stai correndo sudo -H gedit, che è uno dei modi ragionevoli . Tuttavia, quella complessità è un altro motivo per cui le persone tendono a suggerire editor non grafici.
I programmi grafici sono spesso più complicati dei programmi non grafici. Avere più roba eseguita come root è generalmente negativo, in quanto ci sono più modi in cui le cose potrebbero andare storte, anche a causa di possibili bug, anche per caso. (Gli editor di testo non grafici come quelli vimsono anche abbastanza sofisticati, e sono spesso configurati per eseguire numerosi programmi esterni per eseguire varie attività.)
Oltre a eseguire l'editor come root, un altro approccio generale è quello di modificare un file che l'editor è in grado di modificare anche quando è in esecuzione come utente (non root), in modo tale che le modifiche al file vengano propagate al file di proprietà root desiderato cambiare. Sembra astratto perché le specifiche variano considerevolmente. Seguono due importanti approcci concreti.
sudoedit
Un modo abbastanza lungo per farlo è sudoedit(documentato nella stessa pagina di manuale disudo ). Per impostazione predefinita, sudoeditutilizza l'editor di testo predefinito , che di solito non è - e non dovrebbe essere - un programma grafico. Ma si può dire che per utilizzare qualsiasi editor attraverso i SUDO_EDITOR, VISUALo EDITOR variabili d'ambiente , che consulta in questo ordine. Quindi puoi eseguire:
VISUAL=gedit sudoedit filename
Sostituisci filenamecon un percorso relativo o assoluto al tuo file.
Ciò crea una copia temporanea del file che si desidera modificare. La copia è di proprietà tua, non di root (o di chiunque sia il proprietario originale). Apre l'editor di testo ed è possibile modificare la copia temporanea. Quando chiudi l'editor di testo, sudoeditcontrolla se hai effettivamente apportato modifiche. Se così fosse, copia i modificati copia temporanea torna all'originale.
Sebbene sudoeditfunzioni con editor grafici, è utile anche per editor basati su terminali. In entrambi i casi, l'editor di testo viene eseguito come te, quindi ha la tua configurazione e altre azioni che esegui in esso diverse dalle modifiche apportate a quel file vengono eseguite da te, il che offre un po ' di protezione da alcuni tipi di errori.
Se lo desideri, puoi impostare una di queste variabili di ambiente in modo persistente. SUDO_EDITORè forse il migliore poiché viene utilizzato per meno altre cose. Tuttavia, se lo si imposta su gedit, tenere presente che comandi come non funzioneranno quando non è disponibile alcuna GUI, come spesso accade (anche se non sempre ) in una console virtuale o tramite SSH .sudoedit filename
Il back-end dell'amministratore di GVFS
Un altro modo più recente per farlo è aprire il file attraverso il suo admin://percorso GVFS piuttosto che il suo tradizionale percorso in stile Unix. Grazie a Pomsky per avermi insegnato a riguardo. Proprio come ci sono percorsi GVFS per la modifica di file che, per altri aspetti, non si trovano in una posizione comoda per essere modificati, ad esempio perché si trovano su una macchina remota a cui sei connesso tramite SSH, GVFS supporta admin://percorsi per la modifica di file non possiedi.
Questo è concettualmente simile al fatto sudoeditche esegui l'editor come te stesso e il file che l'editor vede è qualcosa che è autorizzato a modificare. Il tentativo di aprire il file richiede l'autenticazione; questo non è un modo magico per aggirare le consuete restrizioni di sicurezza.
gedit admin:///path/to/filename
Lì, /path/to/filenamedeve essere un percorso assoluto del file, a partire da /. Quindi ci sono tre /personaggi dopo admin:.
Codifiche e altre cose teoricamente influenzate dalla configurazione dell'editor
La codifica di un file non è realmente influenzata dal fatto che l'editor che usi sia grafico o meno. Alcuni editor, come vim, possono anche operare graficamente (il gvimcomando) o non graficamente (il vimcomando). La semplice risposta alla tua domanda sulle codifiche è che non devi preoccuparti di questo. È abbastanza vicino alla verità che davvero non devi leggere il resto di questa risposta.
Nel attuali (e passati) rilasci di Ubuntu, comandi come sudo nanoe sudo vimcorrono quei redattori come root, ma hanno $HOMEancora impostato per la vostra directory home. Questo significa che gli editor, per impostazione predefinita, useranno la tua configurazione piuttosto che quella di root. Se c'è qualcosa nella tua configurazione di quegli editor (o in un programma che eseguono per fare un po 'del loro lavoro, come git) su codifiche o terminazioni di riga , verrà seguito. Con , ciò non accadrà.sudo -H editor
Alcune persone usano bare sudo(cioè, senza -io -H) per gli editor perché lo vogliono. Ma davvero, dovresti pensarci due volte. Non solo puoi raggiungere questo obiettivo in modo più pulito con un metodo come sudoedit, ma ci sono altri svantaggi di comandi come sudo nanoe sudo vim:
Se la configurazione dell'editor provoca l'esecuzione di qualcosa, viene eseguito come root. Per editor sofisticati come vimquesto, questo può far girare un bel po 'di codice non banale come root. Come accennato in precedenza, avere meno codice eseguito come root è generalmente buono e questo è uno degli argomenti contro l'esecuzione di editor grafici come root.
Se la vimconfigurazione ha numerosi plugin - per esempio, per eseguire l'analisi statica sul codice sorgente durante la digitazione di esso - e la radice di non meno, corre roba come root con rispetto . (Anche meno funziona come root , ma i tuoi plugin funzionano ancora!) Questo è separato dal fatto che il tuo editor sia grafico o meno.sudo -H vim filenamesudo vim filenameVISUAL=vim sudoedit filename
Se la configurazione del tuo editor è interrotta e ti impedisce di modificare facilmente i file, risolverlo potrebbe essere ancora più seccante, poiché si applica anche al root. Questa è solo una seccatura, non un problema difficile da risolvere.
I comandi come sudo vimhanno un po ' lo stesso problema del comando (sconsigliato!) sudo gedit. Se si esegue un editor come vimroot ma senza reimpostare $HOME(come sudo -He sudo -isi farebbe) e si creano file di configurazione autonomi , tali file di configurazione risiederanno nella directory home ma saranno di proprietà di root e la configurazione potrebbe essere in qualche modo interrotta quando in seguito esegui l'editor come te stesso.
Bene, questo suona molto simile a quel problema! Il motivo per cui è meno importante rispetto alle applicazioni grafiche è che l'editor di solito si avvia ancora, i messaggi di errore sono di solito più facili da capire, di solito puoi capire quali file specifici sono interessati molto più facilmente e la rottura è in genere limitata quell'unico programma. (I programmi grafici utilizzano i file di configurazione in più punti.) Inoltre, diversamente dagli editor grafici, è improbabile che gli utenti che usano casualmente un editor di testo e non modifichino deliberatamente la sua configurazione abbiano questo problema.
Ancora una volta, è possibile utilizzare la configurazione dell'editor del proprio account utente evitando problemi di autorizzazione utilizzando sudoedito, dal desktop, avviando l'editor normalmente ma accedendo al file tramite un admin://percorso.
Infine, si noti che il comportamento sopra menzionato di sudoquando -Ho -iè passato è effettivamente programmato per cambiare in una versione futura di Ubuntu (come già ha fatto, anni fa, nella maggior parte dei sistemi operativi simili a Unix che usano sudo). Il comportamento è già cambiato in Ubuntu 19.10 , che è la versione di sviluppo al momento della stesura di questo documento.
-Hparte è importante , non utilizzaresudoper avviare applicazioni GUI senza di essa.