Ni
xdg-open some_file
ni
$EDITOR some_file
est infaillible, à moins que vous ne définissiez "default" comme ce qu’ils invoquent, ce qui n’est pas le sens dans lequel il est couramment utilisé.
Par exemple, sur mes systèmes xenial:
Je n'ai pas de variable globale EDITOR définie:
$ env | grep EDITOR
$ echo $EDITOR
$
Donc, $EDITOR some_file
échoue complètement dans un environnement graphique (x & amp; openbox, dans lxterminal), ou dans un tty.
Dans un environnement gui, xdg-open some_file
ouvre le fichier dans vi. Dans un simple tty, il tente de faire de même, mais échoue. Mais vi n'est pas mon éditeur "par défaut" au sens où le mot est le plus couramment utilisé. Tous les gestionnaires de fichiers que j'ai installés conviennent que mon éditeur par défaut est ed
(non, pas que ed
- si j'étais masochiste, j'utiliserais vi
, mon ed
est un script que j'ai écrit). / p>
Il peut être justifié de définir "default" en fonction de l’une ou l’autre de ces commandes, mais dans l’usage général de la grande majorité des utilisateurs, "default" est un adjectif appliqué à tout programme ouvrant un fichier lorsque vous double-cliquez ou double-cliquez dessus dans un navigateur de fichiers gui (comme Nautilus, Pcmanfm, Thunar, etc.), (double ou simple selon les paramètres de ce navigateur de fichiers PARTICULIER). Ou, alternativement, quel que soit le programme qui ouvre le fichier lorsque vous le mettez en surbrillance et appuyez sur Entrée dans un navigateur de fichiers orthodoxe tel que Midnight Commander.
Donc, dans l'utilisation la plus courante de "default", vous pouvez avoir une valeur par défaut différente pour chaque navigateur de fichiers, et lorsque vous parlez de défaut sans qualification, cela signifie que le navigateur par défaut est celui par défaut. Et le navigateur de fichiers par défaut dans un environnement graphique serait celui qui s'ouvre si vous double-cliquez sur un répertoire (aka "folder") ou un lien symbolique vers un répertoire du bureau, ou si vous n'utilisez pas la métaphore du bureau, le plus en vedette dans un menu. Pour autant que je sache, dans ce sens, qui est l'utilisation normale du monde réel, la réponse de Sumeet Deshmukh est totalement correcte et totalement complète. Cela peut aussi être dans les sens les plus abstraits.
Dans un environnement non graphique, en dehors d’un gestionnaire de fichiers orthodoxe, le sens commun du mot "default", appliqué à un éditeur, n’a pas d’application normale. Personne travaillant dans tty n'invoque un éditeur avec xdg-open some_file
ou $EDITOR some_file
à moins qu'ils ne travaillent sur la machine de quelqu'un d'autre, ne veulent pas installer quoi que ce soit et se retrouvent désespérés. Ils ouvrent un éditeur en invoquant directement celui qu'ils veulent ouvrir, BY NAME. S'ils obtiennent bash: gedit: command not found
, ils essaient leur deuxième favori, etc. La valeur par défaut est sans importance. Tout ce qui compte, ce sont leurs préférences et ce qui est installé ou peut être installé.
Le point principal:
. . . gksu gedit /path/file.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 déclaration est fausse et pourquoi cette commande a échoué. L'éditeur par défaut, quelle que soit sa définition, n'est pas pertinent.
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 disposer des 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 peuvent nécessiter w sur le fichier ou même sur le répertoire parent, mais ils ne le devraient pas.
Vous devriez être capable de savoir pourquoi la commande a échoué en lisant le message d'erreur. Si vous aimez gedit, installez-le.
Mais le gksu est dangereux. Utilisez gksudo si vous en avez besoin. Mais n'utilisez aucune des commandes de type su / sudo / gksu / gksudo / pkexec à moins que la commande suivante échoue sans elle. Et même alors, seulement si cela devait échouer. Si cela a dû fonctionner, utiliser une commande sudo-ish pour FAIRE que cela fonctionne est comme "Si ça ne rentre pas, obtenir un marteau plus gros". Cela créera plus de problèmes par la suite. Dans ce cas, corrigez les autorisations et essayez de comprendre pourquoi elles étaient incorrectes.
Les commandes de type sudo ne sont pas non plus omnipotentes. Parfois, vous devez modifier les autorisations avant de pouvoir modifier le fichier, même avec gksudo.
En ce qui concerne les dangers de gksu
, écoutez Paddy qui a commenté la réponse de Sumeet. Il est un gars sage qui a été autour depuis un certain temps. 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