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 -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gedit in Ubuntu. https://bugs.launchpad.net/bugs/796076 Title: When run as root [gksudo gedit <whatever>] gedit tries to open a 2nd 'untitled document 1' To manage notifications about this bug go to: https://bugs.launchpad.net/gedit/+bug/796076/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs