vim ri-modifica come root

28

Apro spesso un file in vim, apporto alcune modifiche e quando è il momento di salvare il file è di sola lettura .. (di proprietà di un altro utente). Sto cercando suggerimenti su come riaprire il file come root e conservare le mie modifiche senza prima salvarlo in un file temporaneo per copiarlo o modificarlo nuovamente come root.

— rkthkr
fonte

42

Da questa risposta stackoverflow , da skinp

:w !sudo tee %
Mi dimentico spesso di sudo prima di modificare un file su cui non ho i permessi di scrittura. Quando vengo per salvare quel file e ottengo un errore di autorizzazione, emetto semplicemente quel comando vim per salvare il file senza la necessità di salvarlo in un file temporaneo e quindi copiarlo di nuovo.

— dbr
fonte

Questo è quasi .. Ma sarebbe bello riavviare vim ed eseguirlo come root .. Questo è il mio preferito finora :)

— rkthkr

@rkthkr, se "vim è stato riavviato ed eseguito come root" non saresti in grado di salvare le modifiche apportate e perdere la cronologia degli annullamenti. Ma se questo è quello che vuoi ... [È uscito dai personaggi.] Vedi la "risposta" che sto per scrivere.

— Bruno Bronosky,

2

@dbr, penso che valga la pena ricordare che dopo aver sovrascritto il file (con tee come sudo), ti verrà richiesto con [O] k o [L] oad. L'opzione successiva cancellerà la cronologia degli annullamenti e resetterà il "flag modificato" consentendoti di uscire senza essere avvisato di salvare le modifiche. La prima opzione, che preferisco, manterrà la cronologia degli annullamenti, ma ti farà avvisare quando tenti di uscire. Devi usare: q! per uscire in questo caso. Faccio questo in modo da poter validare (es .:! Sudo /etc/init.d/httpd configtest) e rollback / reedit se necessario.

— Bruno Bronosky,

15

Per favore, non votatemi per questo. Non consiglio di implementare questa risposta, ma è la risposta richiesta da rkthkr.

rkthkr ha detto:
Ma sarebbe bello riavviare Vim ed eseguirlo come root

Il modo per farlo è con :!sudo vim %
Come ho già detto a ipozgaj, un% come argomento (anche un argomento secondario) viene sostituito con il percorso del buffer corrente. (È possibile che venga richiesta la password.) Si finisce con un nuovo processo vim, di proprietà di root, che è un processo figlio del processo vim originale. Sembra sciocco, vero? Ecco come appare in ps:

~# ps afo pid,ppid,user,stat,comm
  PID  PPID USER         STAT COMMAND
16187 30478 rbronosky    Ss   bash
16510 16187 rbronosky    R+    \_ ps
30482 30478 rbronosky    Ss   bash
16244 30482 rbronosky    S+    \_ vim
16318 16244 root         S+        \_ vim

Se si dispone delle autorizzazioni di scrittura per la directory che contiene il file e sono state apportate modifiche, è possibile che venga emesso un file di scambio. La scelta di [R] ecover, rifletterà la maggior parte * delle modifiche apportate dal processo vim padre. (* Penso che forse l'aggiornamento di swap sia cronometrato o abbia una soglia delta. Ho già dedicato troppo tempo a questo e non mi interessa fare ricerche.) Quando vai e esci da VIM, non allarmarti quando sei ancora in vim ... hai aperto un secondo processo vim. Ricorda?

Ora, detto tutto questo ... non lo farei quasi mai. Forse, se non avessi avuto abbastanza caffè o troppo, e mi sono reso conto che avrei dovuto modificare molti altri file come root ... Potrei provare questo. In 14 anni di amministrazione dei sistemi, non l'ho mai fatto. Ma fino a quando non hai espresso malcontento con la mia soluzione preferita (che è esattamente come offerta da dbr) non ci avevo mai pensato.

— Bruno Bronosky
fonte

Grazie Richard! Molto istruttivo, ti darò +1 per questo :)

— rkthkr il

Questa è una risposta di altissima qualità: perché votare verso il basso? +1 anche da me.

— Mei,

1

Grazie @Richard Bronosky, nel mio gvim non è possibile digitare la password sudo con, :w !sudo tee %quindi penso che questa sia una buona risposta.

— Eric Fortis,

1

Di solito lo salvo in un file temporaneo in $ HOME / tmp / apache.conf (per esempio)

sudo vimdiff $HOME/tmp/apache.conf /etc/apache2/apache.conf

questo è un lavoro extra per unire le modifiche ma ha dato i suoi frutti. Trovo che sia un bel modo tra convenienza e misurazioni contro cambiamenti indesiderati

Prima pensavo agli ACL o all'assegnazione di gruppi corrispondenti ai file, ma spesso non funzionava tutto, o mi ero dimenticato di cambiare le proprietà o stavo cambiando i file dove non intendevo farlo.

Questo vale solo per i file che non sono stati gestiti fino ad ora. La soluzione complessiva che utilizziamo è fantoccio con un repository git in cui le persone modificano i file localmente e testano le modifiche sui server appropriati, se la configurazione funziona come desiderato le modifiche vengono reimmesse nel repository centrale dove il nostro motore di configurazione estrae le modifiche a intervalli regolari.

— serverhorror
fonte

0

Quello che faccio normalmente - non necessariamente il più veloce, ma sicuramente sicuro - è fare qualcosa del genere (usando nsswitch.conf come esempio):

:w! ~/%

Esci da vim, quindi esegui:

sudo vim nsswitch.conf
1GdG
:r ~/%

Ciò eliminerà tutte le righe e leggerà la versione modificata e aggiornata da modificare al suo posto. L'uso della tua home directory significa che non devi pensare se hai accesso o meno - ed è più privato di / tmp. Nota bene che si tratta di una sostituzione di file intero: se non vuoi aggiungere tutte le modifiche, dovrai scegliere.

Nonostante il mal di testa coinvolto in una di queste risposte, non c'è motivo di perdere le modifiche.

— Mei
fonte