Non plus
xdg-open some_file
ni
$EDITOR some_file
n'est infaillible, sauf si vous DÉFINISSEZ "par défaut" comme tout ce qu'ils invoquent, ce qui n'est pas le sens dans lequel il est communément utilisé.
Par exemple, sur mes systèmes xenial :
Je n'ai pas de variable EDITOR globale définie :
$ env | grep EDITOR
$ echo $EDITOR
$
Ainsi, $EDITOR some_file échoue complètement dans un environnement graphique (x & openbox, dans lxterminal), ou dans une TTY.
Dans un environnement graphique, xdg-open some_file ouvre le fichier dans vi. Dans une simple TTY, cela TENTE de faire la même chose, mais échoue. Mais vi n'est pas mon éditeur "par défaut" dans le sens le plus couramment utilisé du mot. Tous les gestionnaires de fichiers que j'ai installés conviennent que mon éditeur par défaut est ed (non, pas CE ed - si j'étais masochiste, j'utiliserais vi, mon ed est un script que j'ai écrit).
Il peut y avoir une justification à définir "par défaut" en fonction de l'une ou l'autre de ces commandes, mais dans l'utilisation générale de la grande majorité des utilisateurs, "par défaut" est un adjectif appliqué à tout programme qui ouvre un fichier lorsque vous double-cliquez ou cliquez dessus dans un navigateur de fichiers graphique (comme Nautilus, Pcmanfm, Thunar, etc.) (double ou simple selon les paramètres de ce navigateur de fichiers PARTICULIER). Ou, en outre, tout programme qui ouvre le fichier lorsque vous le mettez en surbrillance et appuyez sur Entrée dans un gestionnaire de fichiers orthodoxe comme Midnight Commander.
Ainsi, dans l'utilisation la plus courante de "par défaut", vous pouvez avoir un paramètre par défaut différent pour chaque gestionnaire de fichiers, et lorsque vous parlez de par défaut sans qualification, cela signifie ce qui est le cas par défaut dans le navigateur de fichiers par défaut. Et le navigateur de fichiers par défaut dans un environnement graphique serait celui qui s'ouvrirait si vous double-cliquez sur un répertoire (également appelé "dossier") ou un lien symbolique vers un répertoire sur le bureau, ou si vous n'utilisez pas la métaphore du bureau, peut-être celui le plus présent dans un menu. Autant que je sache, dans ce sens, qui est l'usage normal du monde réel, la réponse de Sumeet Deshmukh est totalement correcte et totalement complète. Cela peut être le cas dans des sens plus abstraits également.
Dans un environnement non graphique, en dehors d'un gestionnaire de fichiers orthodoxe, le sens commun du mot "par défaut", appliqué à un éditeur, n'a pas d'application normale. Personne travaillant dans une TTY n'invoque un éditeur avec xdg-open some_file ou $EDITOR some_file sauf s'il travaille sur la machine de quelqu'un d'autre, ne veut rien installer et est devenu désespéré. Ils ouvrent un éditeur en invoquant directement celui qu'ils veulent ouvrir, PAR NOM. S'ils obtiennent bash: gedit: commande introuvable, ils essaient leur deuxième favori, etc. Peu importe ce que le paramètre par défaut est, tout ce qui compte, ce sont leurs préférences et ce qui est installé ou peut être installé.
Le Point Principal :
. . . gksu gedit /chemin/fichier.txt qui ne fonctionnera pas car gedit n'est pas l'éditeur de texte par défaut . . . .
Faux. Et c'est pourquoi j'ai posté, pour expliquer pourquoi cette affirmation est fausse et pourquoi cette commande a échoué. Peu importe quel est l'éditeur par défaut, quoi que vous en définissiez, cela n'a pas d'importance.
Pour que cette commande fonctionne, vous avez besoin de 2 choses :
-
Les deux programmes, gksu et gedit, doivent être installés sur le système.
-
Vous devez avoir les autorisations appropriées pour le fichier et ses répertoires ancestraux. Vous devez avoir x sur tous les répertoires du chemin, au moins r sur le fichier lui-même, et probablement au moins r sur le répertoire parent. Certains éditeurs pourraient nécessiter w sur le fichier ou même sur le répertoire parent, bien qu'ils ne devraient pas.
Vous devriez être capable de comprendre pourquoi la commande a échoué en lisant le message d'erreur. Si vous aimez gedit, installez-le.
Mais gksu est dangereux. Utilisez gksudo si vous en avez besoin. Mais n'utilisez aucun des commandes de type su/sudo/gksu/gksudo/pkexec si la commande qui suit échoue sans. Et même dans ce cas, seulement si elle DEVRAIT avoir échoué. Si cela aurait dû fonctionner, utiliser une commande sudo pour le FAIRE fonctionner est comme "Si ça ne rentre pas, obtenez un plus gros marteau". Cela créera plus de problèmes à l'avenir. Dans ce cas, corrigez les autorisations et essayez de comprendre pourquoi elles étaient incorrectes en premier lieu.
Aucune des commandes de type sudo n'est omnipotente. Parfois, vous DEVEZ modifier les autorisations avant de pouvoir modifier le fichier même AVEC gksudo.
Concernant les dangers de gksu, écoutez Paddy qui a commenté la réponse de Sumeet. C'est un type sage qui a de l'expérience. En répétant ses 3 liens :
https://askubuntu.com/a/288506/2088
https://bugs.launchpad.net/ubuntu/+source/gksu/+bug/1186676
http://ubuntuforums.org/showthread.php?t=1819589
