Comment 24 for bug 796076

its pretty queer:

when doing a sudo su, and then as root gedit <anyfile> , no second "untitled document 1" is opened. but when using gksu/gksudu it is; in the latter case ps shows that the command line that started gedit was exactly this "gedit <anyfile>.

this additional "untitled document 1" always has the "changed" mark (leading asterisk) but: nothing has happened to it, undo is inactive, and it has no contents: when saved it has zero bytes.

tried to find out what gksu really did by "strace -f gksu gedit /etc/fstab" and found it does:
 execve("/usr/bin/sudo", ["/usr/bin/sudo", "-H", "-S", "-p", "GNOME_SUDO_PASS", "-u", "root", "--", "gedit", "/etc/fstab"], [/* 38 vars */]) = 0
more readable:
/usr/bin/sudo -H -S -p GNOME_SUDO_PASS -u root -- gedit /etc/fstab
which means: set home to /root, read password from stdin, and prompt with GNOME_SUDO_PASS (triggers gksu to output the pass phrase)
when I issue this very command in a xterm and enter my password after the prompt gedit opens without this dummy untitled document, but with exactly the same execve call it does? I have no clue ...

so summarizing:
- not caused by wrong setting in root's account
- not caused by wrong command from gksu
- caused by a different handling of the execve system call in contrast to the shell?

this is on a newly set up maya mint system, but running gnome-classic from precise repositories

btw: regarding the #23 desktop file:
grep Exec /usr/share/applications/gedit.desktop ->
Exec=gedit %U
Exec=gedit --new-window
Exec=gedit --new-window