It depends. Graphical programs usually use the same methods as non-graphical ones; that is, one of:
Sometimes the program hands a list of parameters directly to the kernel, using something along the lines of:
if (fork() == 0)
execlp("vim", "--remote-tab-silent", "/home/LeNoob/somefile.txt", NULL);
exec*() functions tell the kernel, "run exactly this thing and pass it this exact list of command-line options into
Other times, programs will ask the shell –
/bin/sh – to interpret a command line:
It's practically the same shell as in terminals, but is run in non-interactive mode using the
-c option. Also, it's always
/bin/sh by convention, regardless of what shell (bash, zsh...) you've chosen to use interactively. So the above is rougly the same as:
if (fork() == 0)
execl("/bin/sh", "-c", "vim $HOME/.bashrc");
(The shell itself, of course, will use
Finally, desktop environments that use D-Bus can use it to start various services by simply sending a message to the desired "bus name" (e.g.
org.gnome.gedit). Also known as "bus activation", when dbus-daemon sees a program sending a message to a bus name that nothing currently "owns", it searches its configuration for the program's path, and again uses exec() to start it.
This is a commonly used D-Bus feature, but mostly just for background services like "dconf". In the future, GNOME is planning to use this to also start regular apps like Nautilus or Gedit as well. However, right now, it uses the same method as all other DEs do, by reading the relevant
.desktop file [see below] and exec()'ing the program directly, so I'm only including this for completeness.
(Of course, real programs do not have
"somefile.txt" hardcoded in them – they use something like
getenv("EDITOR") and the desired file name – but you get the point.)
However, none of this actually matters, since the shell never interprets aliases in non-interactive mode, and while it would interpret shell functions, it will never read your
~/.bashrc to see which functions you have defined.
So the next questions are, how do you configure gVim as your text editor; and does your program search for
gvim in $PATH directories, or does it take the full path
/usr/bin/gvim from its configuration file?
Terminal-based programs use the
$EDITOR variable, so instead of
EDITOR=gvim you could use
EDITOR="gvim --remote-tab-silent" in your ~/.profile or similar.
Desktop environments find gVim according to
/usr/share/applications/gvim.desktop – specifically, the line
Exec=gvim -f %F, which only tells them to start
gvim but doesn't say where it is, so $PATH will be used. This means it can be overridden in two ways:
you could make a script that wraps
gvim and put it somewhere early in $PATH – for example, call the script
~/bin/gvim then put
~/bin at the beginning of $PATH;
or you could copy the .desktop file from /usr to
~/.local/share/applications/gvim.desktop, and change the
Exec= line to have the desired options:
Exec=gvim --remote-tab-silent -f %F
(Normally the changes will be picked up immediately, but if they don't, try running
kbuildsycoca4 --noincremental from a terminal.)