is foolproof, unless you DEFINE "default" as whatever they invoke, which is not the sense in which it is commonly used.
For example, on my xenial systems:
I don't have a global EDITOR variable defined:
$ env | grep EDITOR
$ echo $EDITOR
$EDITOR some_file fails completely in either a gui environment (x & openbox, in lxterminal), or in a tty.
In a gui environment
xdg-open some_file opens the file in vi. In a plain tty, it ATTEMPTS to do the same, but fails. But vi is not my "default" editor in the sense the word is most commonly used. All the file managers I have installed agree that my default editor is
ed (no, not THAT
ed - if I were that masochistic I'd use
ed is a script I wrote).
There may be a justification for defining "default" in terms of one or the other of those commands, but in the general usage of the great majority of users, "default" is an adjective applied to whatever program opens a file when you double or single click on it in a gui file browser (like Nautilus, Pcmanfm, Thunar, etc.), (double or single depending on the settings in that PARTICULAR file browser). Or, alternately, whatever program opens the file when you highlight it and press enter in an orthodox file browser like Midnight Commander.
So, in the most common usage of "default", you can have a different default for each file browser, and when you speak of default without qualification it means whatever is the default in the default file browser. And the default file browser in a graphical environment would be the one that opens if you double click on a directory (aka "folder") or a symlink to a directory on the desktop, or if you don't use the desktop metaphor, maybe the one most featured in a menu. As far as I know, in this sense, which is the normal real world usage, Sumeet Deshmukh's answer is totally correct and totally complete. It may be in the more abstract senses as well.
In a non-graphical environment, outside of an orthodox file manager, the common sense of the word "default", applied to an editor, has no normal application. Nobody working in tty invokes an editor with
xdg-open some_file or
$EDITOR some_file unless they are working on somebody else's machine, don't want to install anything, and have gotten desperate. They open an editor by directly invoking the one they want to open, BY NAME. If they get
bash: gedit: command not found they try their second favorite, etc. What the default is, is irrelevant. All that matters is their preferences and what's installed or can be installed.
The Main Point:
. . . gksu gedit /path/file.txt which wont work because gedit isn't the default text editor . . . .
Wrong. And that's why I posted, to explain why that statement is wrong and why that command failed. What the default editor is, however you define it, is irrelevant.
For that command to work, you need 2 things:
gedit, must be installed on the system.
You must have suitable permissions for the file and it's ancestral directories. You have to have x on all directories in the path, at least r on the file itself, and probably at least r on the parent directory. Some editors might require w on the file or even on the parent directory, although they shouldn't.
You should be able to tell why the command failed by reading the error message. If you like gedit, install it.
But gksu is dangerous. Use gksudo if you need it. But don't use any of the su/sudo/gksu/gksudo/pkexec type commands unless the command that follows fails without it. And even then, only if it SHOULD have failed. If it should have worked, using some sudo-ish command to MAKE it work is like "If it don't fit, get a bigger hammer". It will create more problems down the road. In that case, correct the permissions , and try to figure why they were wrong in the first place.
Nor are any of the sudo type commands omnipotent. Sometimes, you MUST change permissions before you can edit the file even WITH gksudo.
Regarding the dangers of
gksu listen to Paddy who commented on Sumeet's answer. He is wise chap who has been around a while. Repeating his 3 links: