Né
xdg-open some_file
né
$EDITOR some_file
è infallibile, a meno che DEFINI "default" come qualunque cosa invochino, il che non è il senso in cui viene comunemente usato.
Ad esempio, sui miei sistemi xenial:
Non ho una variabile EDITOR globale definita:
$ env | grep EDITOR
$ echo $EDITOR
$
Quindi $EDITOR some_filefallisce completamente in un ambiente gui (x & openbox, in lxterminal) o in un tty.
In un ambiente gui xdg-open some_fileapre il file in vi. In poche parole, TENTA di fare lo stesso, ma fallisce. Ma vi non è il mio editor "predefinito" nel senso che la parola è più comunemente usata. Tutti i file manager che ho installato concordano sul fatto che il mio editor predefinito è ed(no, non QUELLO ed- se fossi così masochista che userei vi, il mio edè uno script che ho scritto).
Potrebbe esserci una giustificazione per definire "default" in termini di uno o l'altro di quei comandi, ma nell'uso generale della stragrande maggioranza degli utenti, "default" è un aggettivo applicato a qualunque programma apre un file quando si raddoppia o fai clic su di esso in un browser di file gui (come Nautilus, Pcmanfm, Thunar, ecc.), (doppio o singolo a seconda delle impostazioni in quel PARTICOLARE file browser). Oppure, in alternativa, qualunque programma apre il file quando lo evidenzi e premi Invio in un browser di file ortodosso come Midnight Commander.
Pertanto, nell'uso più comune di "predefinito", è possibile avere un valore predefinito diverso per ciascun browser di file e quando si parla di valore predefinito senza qualifica significa qualsiasi valore predefinito nel browser di file predefinito. E il browser di file predefinito in un ambiente grafico sarebbe quello che si apre se fai doppio clic su una directory (aka "cartella") o un collegamento simbolico a una directory sul desktop, o se non usi la metafora del desktop, forse quello più presente in un menu. Per quanto ne so, in questo senso, che è il normale utilizzo nel mondo reale, la risposta di Sumeet Deshmukh è totalmente corretta e completa. Potrebbe essere anche nei sensi più astratti.
In un ambiente non grafico, al di fuori di un file manager ortodosso, il senso comune della parola "default", applicato a un editor, non ha una normale applicazione. Nessuno che lavora in tty invoca un editor con xdg-open some_fileo, a $EDITOR some_filemeno che non stia lavorando sulla macchina di qualcun altro, non voglia installare nulla e sia diventato disperato. Aprono un editor invocando direttamente quello che vogliono aprire, PER NOME. Se arrivano bash: gedit: command not foundprovano il loro secondo preferito, ecc. Qual è il valore predefinito, è irrilevante. Tutto ciò che conta sono le loro preferenze e ciò che è installato o può essere installato.
Il punto principale:
. . . gksu gedit /path/file.txt che non funzionerà perché gedit non è l'editor di testo predefinito. . . .
Sbagliato. Ed è per questo che ho pubblicato, per spiegare perché quell'affermazione è sbagliata e perché quel comando non è riuscito. Qual è l'editor predefinito, indipendentemente dal modo in cui lo definisci, è irrilevante.
Perché quel comando funzioni, hai bisogno di 2 cose:
Entrambi i programmi gksue gedit, devono essere installati sul sistema.
È necessario disporre delle autorizzazioni adeguate per il file e le relative directory ancestrali. Devi avere x su tutte le directory nel percorso, almeno r sul file stesso e probabilmente almeno r sulla directory padre. Alcuni editor potrebbero richiedere w sul file o addirittura sulla directory padre, anche se non dovrebbero.
Dovresti essere in grado di capire perché il comando non è riuscito leggendo il messaggio di errore. Se ti piace gedit, installalo.
Ma il gksu è pericoloso. Usa gksudo se ne hai bisogno. Ma non usare nessuno dei comandi di tipo su / sudo / gksu / gksudo / pkexec a meno che il comando che segue fallisca senza di esso. E anche allora, solo se DOVREBBE fallire. Se avrebbe dovuto funzionare, usare un comando sudo-ish per FARLO funziona come "Se non si adatta, prendi un martello più grande". Creerà più problemi lungo la strada. In tal caso, correggi le autorizzazioni e prova a capire perché avevano sbagliato in primo luogo.
Né i comandi del tipo sudo sono onnipotenti. A volte, DEVI cambiare i permessi prima di poter modificare il file anche CON Gksudo.
Per quanto riguarda i pericoli gksudell'ascolto di Paddy che ha commentato la risposta di Sumeet. È un saggio ragazzo che è in giro da un po '. Ripetendo i suoi 3 collegamenti:
https://askubuntu.com/a/288506/2088
https://bugs.launchpad.net/ubuntu/+source/gksu/+bug/1186676
http://ubuntuforums.org/showthread.php?t=1819589
