Nem
xdg-open some_file
nem
$EDITOR some_file
é infalível, a menos que você DEFINE "padrão" como o que eles invocam, que não é o sentido em que é comumente usado.
Por exemplo, nos meus sistemas xenial:
Não tenho uma variável global EDITOR definida:
$ env | grep EDITOR
$ echo $EDITOR
$
Portanto, $EDITOR some_filefalha completamente em um ambiente de GUI (x & openbox, no lxterminal) ou em um tty.
Em um ambiente de GUI, xdg-open some_fileabre o arquivo no vi. Em um simples exemplo, ele tenta fazer o mesmo, mas falha. Mas o vi não é meu editor "padrão" no sentido em que a palavra é mais comumente usada. Todos os gerenciadores de arquivos que eu instalei concordam que meu editor padrão é ed(não, não ISSO ed- se eu fosse a masoquista que eu usaria vi, meu edé um script que escrevi).
Pode haver uma justificativa para definir "padrão" em termos de um ou outro desses comandos, mas no uso geral da grande maioria dos usuários, "padrão" é um adjetivo aplicado a qualquer programa que abre um arquivo quando você duplica ou clique nele em um navegador de arquivos da interface gráfica do usuário (como Nautilus, Pcmanfm, Thunar, etc.), (duplo ou único, dependendo das configurações desse navegador de arquivos PARTICULAR). Ou, alternativamente, qualquer programa que abrir o arquivo quando você o destacar e pressionar enter em um navegador de arquivos ortodoxo como o Midnight Commander.
Portanto, no uso mais comum de "padrão", você pode ter um padrão diferente para cada navegador de arquivos e, quando você fala de padrão sem qualificação, significa o que é o padrão no navegador de arquivos padrão. E o navegador de arquivos padrão em um ambiente gráfico seria aquele que abrir se você clicar duas vezes em um diretório (também conhecido como "pasta") ou em um link simbólico para um diretório na área de trabalho, ou se você não usar a metáfora da área de trabalho, talvez o mais destacado em um menu. Até onde eu sei, nesse sentido, que é o uso normal do mundo real, a resposta de Sumeet Deshmukh é totalmente correta e totalmente completa. Pode ser também nos sentidos mais abstratos.
Em um ambiente não gráfico, fora de um gerenciador de arquivos ortodoxo, o senso comum da palavra "padrão", aplicado a um editor, não tem aplicação normal. Ninguém trabalhando no tty chama um editor com xdg-open some_fileou a $EDITOR some_filemenos que esteja trabalhando na máquina de outra pessoa, não quer instalar nada e ficou desesperado. Eles abrem um editor chamando diretamente aquele que desejam abrir, POR NOME. Se conseguirem bash: gedit: command not found, tentam seu segundo favorito, etc. Qual é o padrão é irrelevante. O que importa são as preferências e o que está instalado ou pode ser instalado.
O ponto principal:
. . . gksu gedit /path/file.txt que não funciona porque o gedit não é o editor de texto padrão. . . .
Errado. E foi por isso que postei, para explicar por que essa declaração está errada e por que esse comando falhou. O que é o editor padrão, independentemente de como você o define, é irrelevante.
Para que esse comando funcione, você precisa de duas coisas:
Ambos os programas gksue geditdevem estar instalados no sistema.
Você deve ter permissões adequadas para o arquivo e seus diretórios ancestrais. Você precisa ter x em todos os diretórios no caminho, pelo menos r no próprio arquivo e provavelmente pelo menos r no diretório pai. Alguns editores podem requerer w no arquivo ou até no diretório pai, embora não devam.
Você deve saber por que o comando falhou ao ler a mensagem de erro. Se você gosta do gedit, instale-o.
Mas gksu é perigoso. Use gksudo se você precisar. Mas não use nenhum dos comandos do tipo su / sudo / gksu / gksudo / pkexec, a menos que o comando a seguir falhe sem ele. E, mesmo assim, somente se DEVERIA ter falhado. Se deveria ter funcionado, usar algum comando sudo-ish para fazê-lo funcionar é como "Se não couber, pegue um martelo maior". Isso criará mais problemas no caminho. Nesse caso, corrija as permissões e tente descobrir por que eles estavam errados em primeiro lugar.
Nenhum dos comandos do tipo sudo é onipotente. Às vezes, você DEVE alterar as permissões antes de poder editar o arquivo mesmo com o gksudo.
Quanto aos perigos de gksuouvir Paddy, que comentou a resposta de Sumeet. Ele é um sujeito sábio que já existe há algum tempo. Repetindo seus 3 links:
https://askubuntu.com/a/288506/2088
https://bugs.launchpad.net/ubuntu/+source/gksu/+bug/1186676
http://ubuntuforums.org/showthread.php?t=1819589
