When run as root [gksudo gedit <whatever>] gedit tries to open a 2nd 'untitled document 1'

Thanks for your report, I'm seeing this too. This is a regression introduced in Oneiric, in Natty no additional tab is opened.

I've sent this upstream, they might have a better idea on what's going on, the upstream bug is https://bugzilla.gnome.org/show_bug.cgi?id=653563

Hmmnn, so upstream have had notification since June and no action whatsoever ???

see also:

Bug #838404 (more or less) a duplicate of this bug.

Bug #805682 Underlying issues with Nautilus and gksudu

This also occurs in Precise (see duplicate bug 880038).

The strange thing is, unlike the duplicate Bug #838404 says, it ONLY happens with "gksudo", anything else like "sudo", "su" or without this works fine without the annoying "new document 1". My notice on Xubuntu 11.10 Oneiric.

I have to correct myself from before, it's like the Bug #838404, with "gksu" or/and "gksudo".

the same problem here, calling
gksudo gedit anyfile
opens untitled document in addition
Ubuntu Oneiric Ocelot

I have the same problem here on Ubuntu 11.10, quite annoying.
Does anybody know where can I find the root's config file for gedit? I'm sure that causes the problem, because if I run "sudo gedit", the problem doesn't occur. However, starting graphical programs with "sudo" uses the user's config file, not the root's. (therefore should be avoided).

I'd just go ahead & use sudo gedit or sudo -H gedit

Just to add an interesting twist...

I'm running Ubuntu 11.10 (oneiric) and this same bug is happening for me when using gEdit from Konqueror (as a file manager) when clicking on text files. i sometimes run Konqueror with kdesudo first, so that i can access files that only have 'root' permission, but this bug occurs even when i am running Konqueror normally, to access files from my usual Ubuntu username. so it wouldn't be launching them as 'root' would it? and yet... that same behaviour, ie: the unnecessary 'untitled document' also being opened.

this might be a separate bug, but this is the only reference i have found so far to these symptoms. if this should be posted somewhere else (like a Konqueror issue queue) just let me know.

This does happen to me when using gksudo
But it also happens to me when clicking on files in Nautilus, not as sudo.

whoops...turns out this was actually happening to me because of
/usr/share/applications/gedit.desktop had Exec=gedit --new-document %U
(my fault)

I have this problem still in 12.04 Beta.
I had this problem before in Oneric... but kinda got used to it, and just remembered it today when I was doing some
"gksu gedit" work... I also tried "gksudo gedit"
surprisingly "sudo gedit" doesn't open the extra tab, though I don't intend to use sudo instead of gksu, or gksudo.
I am not terribly annoyed, but it is a bug needing to be fixed for the precise release.

Still not fixed in Precise.

Still in 12.04. By `edit as root` user action from krusader.
Annoying bug, solved by using geany instead of gedit

I can confirm that this is still happening.

It's been over a year already -- this simple error does not reflect well on Ubuntu.

I second that this is still happening. I am running 10.04, but the bug happens for me when opening a file over SSH. For example:

ssh -Y remote_machine 'gedit /home/user/Documents/file.txt'

opens file.txt, but also "Untitled Document 1."

If you are interested, I have created a simple workaround for this problem. The how-to is described in the following forum post.

http://ubuntuforums.org/showpost.php?p=12071894&postcount=81

This bug is still present in 12.10 Quantal Quetzal. :(

Here the same problem on ubuntu 12.04. 14 month and still no fix, must be a very complicated bug to solve. :-D

Anyone examined the .desktop file?
If I drag it into the launcher bar, using the "open new document/window" functions work very oddly, opening more than one "ghost" document. If I try to add double quotes the %U, it tries to open $HOME/Documents (which is a folder, won't work). I can also reproduce the original bug.
It's weird because when done manually, gedit seems to behave nicely if invoked from the command line, but seems to fail when the .desktop file is used. So maybe it has something to do with it.
For example, if I run gedit and use the launcher shortcut to open a new document, it doesn't work (opens another window with ghost documents), but if I try from command line (gedit --new-document) , it'll open a new document as expected.

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

Temporary SOLUTION:

I've found another workaround. Unfortunately for us this doesn't seems to be a bug, at least I guess there's no intention from gnome developers to solve it soon:

A upstream developer said: "You shouldn't start GNOME programmes with elevated privileges, it's not supported. In any case, not a gnome-terminal bug". It's not just nautilus it's any gnome application with a GUI.

This can be confirmed according to the upstream of the Nautilus bug, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/805682, at Gnome bugzilla (https://bugzilla.gnome.org/show_bug.cgi?id=654184). It's clear that Gnome developers don't design their programs to be runned as root.

So, since they don't want to support gnome graphical programs as root, it's not a bug. If you can read more about why they don't support this you can read:
- http://ubuntuforums.org/showthread.php?t=2014450
- https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1019995

But it IS a problem if we want to start gnome graphical programs as root. So we need alternative solutions:

- Paddy Landau have created a workaround for it (comment #20) and posted it at http://ubuntuforums.org/showpost.php?p=12071894&postcount=81.
- You can use alternative applications (like graphical leafpad or vim and nando in the terminal).
- Running sudo gedit (NOT recommended, graphical programs should be runned with gksudo or kdesudo)
- The simplest solution I got. (See down).

As Derek White posted in https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/890041.

$ gedit # opens untitled document
$ gedit /path/to/file # opens file
$ sudo gedit /path/to/file # opens file
$ gksu gedit /path/to/file # opens file & untitled document
$ gksudo gedit /path/to/file # opens file & untitled document

I figured out that it only happens when you try to gksudo with other user. For example:

$ gksudo -u userA /path/to/file # Will opens file normally if logged as userA.
$ gksudo /path/to/file # Will also opens normally if you're logged as root (with sudo -i or something).

But if you are root and try to gksudo with other user it will brings the untitled document again:

$ gksudo -u UserA /path/to/file # Will opens file & untitled document.

So, as long as we are supossed to run graphical applications with gksudo, the solution is to be logged as root and run gedit with gksudo (whitout parameters it'll run as root). If you want to do this in one single line you can do:

$ sudo gksudo gedit /path/to/file # Works perfectly.
$ gksudo gksudo gedit /path/to/file # Works perfectly. I recomend this, specially if you want to call gedit in a script or something.

That's it!

I wish this can help to devs to deciding fix this problem an support graphical as root. Or someone else to add the feature to Gnome applications.

Yep same behavior here as well with Ubuntu 12.10x64.

@Freecore: Thank you for your comments.

For whatever reason (probably the post is too old), I cannot edit my original post; but your "gksudo gksudo" is so much easier than my solution. And weird!

I'll probably get my hands slapped for this; but in the interim you can create an alias so that you do not have to type 'gksudo gksudo' or 'gksu gksu' each time:

$ gedit ~/.bashrc

Scroll down the the alias section & add the last two lines shown here:

# some more ls aliases
#alias ll='ls -l'
#alias la='ls -A'
#alias l='ls -CF'
alias gksudo='gksudo gksudo'
alias gksu='gksu gksu'

Save & exit. Then:

$ . ~/.bashrc
Note that there is a space following the first dot (.).

@NoOp: An alias is fine, unless you are using Alt-F2 to run the command.

But don't set gksudo to 'gksudo gksudo', because only gedit has this problem. Rather set another name. I have created an executable file called ggedit in my path (~/bin), and it contains just one line:

gksudo gksudo gedit "${@}"

I don't believe I've ever seen anyone specifically show where sudo gedit causes any issue.
I generally will use nano but at times will use sudo gedit.

@paddy-landau While I agree that alias for gksudo is not a good solution since only gedit requires this workaround instead of creating an executable file you can just add an alias for ggedit:
alias ggedit='gksudo gksudo gedit'

On 11/13/2012 10:44 AM, Isamu Arai wrote:
> @paddy-landau While I agree that alias for gksudo is not a good
> solution since only gedit requires this workaround instead of
> creating an executable file you can just add an alias for ggedit:
> alias ggedit='gksudo gksudo gedit'
>

Nice tip. Thanks.

@Isamu Arai: As stated in comment #29, an alias is no good if you are using Alt-F2 to run the command. That is why I use an executable file within a path.

The best workaround for me is this: I switched to Leafpad. I only use Gedit now for non-root tasks; Leafpad works fine when run as root...

Thanks for the interest to the issue but could you move the discussion to an user forum or list? the bug tracker is made to discuss fixes, not to have a nice chat about what's the best or more broken workaround people can come with, every comment added there is "spamming" the people subscribed to gedit...

Sure. But when a 17 month old regression hasn't been fixed (perhaps due to non-technical reasons), I fail to see why adding 'workarounds' to the bug is discouraged.

having a workaround in the bug is fine, having 15 comments in a week to discuss the said workaround not so since it's spamming the people subscribed to gedit bugs where that's not a gedit issue

Bug is still present in Raring Ringtail

This bug has been reported on the Ubuntu Package testing tracker.

A list of all reports related to this bug can be found here:
http://packages.qa.ubuntu.com/qatracker/reports/bugs/796076

Still happening in 13.04 with all documents, not just super user.

Fixed in gedit-3.7.2 & greater

@Doung McMahon: Fantastic.

Will the new version of gedit be released with 13.04?

Is there any possibility to back-port it to LTS?

@Scott: > Still happening in 13.04 with all documents, not just super user.

you should open a new bug about that, this issue is specifically about gksudo (which should be used nowadays, we are replacing it by pkexec in the standard desktop)

I have a workaround for those LTS users like me who haven't got the fixed gedit. As stated if gksudo gksudo gedit is run, it doesn't create the empty document. Therefore, adding this:
gksudo()
{
 if [ "$1" = "gedit" ]
 then
  shift
  gksudo gksudo gedit "$@"
 else
  command gksudo "$@"
 fi
}
to your .bashrc will fix it. For those who don't know bash, it's a function that will be called when the user types gksudo. If the second argument is gedit, then it shifts the argument array, to drop off the first, and then passes the argument array to gksudo gksudo gedit. (This makes sure that if the users specifies a file to open it will get opened). Otherwise it just runs gksudo for us.

@samuel - Thanks for the function. Unfortunately, that only works from the terminal; it doesn't work from Alt+F2.

For that reason, the simplest method is to create a new file (I call it "ggedit"), place it in your path, and make it executable. The file contains just one line:

gksudo gksudo gedit "${@}"

Use "ggedit" (or whatever you call the script) instead of "gksudo gedit", and this will work from Alt+F2, the terminal, or anywhere else.

This annoying little quirk just started happening in Ubuntu 12.04 LTS, however it always has occurred in 12.10, 13.04, 13.10 as well as Mint 13 and 15.
I added the workaround samuel mentioned as I only ever use this in terminal.

@cavsfan: This has been happening since 11.10. If this has only recently started with you, and was working beforehand, it would be interesting and useful to find out what happened!

It is marked as fixed here and at Gnome Bugzilla; however, the fix is in Gedit 3.7. I can't get that version from software updates. Seriously Ubuntu! If there is a fix, send it to all supported distributions. I don't care what your release cycle is.

If it is fixed, then activate the update in all supported distributions! Don't make us wait for an release upgrade!

I can also confirm this occurs with kdesudo. I'm using Kubuntu, but I have gedit installed.

By the way:
That doesn't happen in Arch, so it seems to be an Ubuntu Issue, not a Gnome issue.

On 07/14/2013 03:02 PM, Bazon wrote:
> By the way:
> That doesn't happen in Arch, so it seems to be an Ubuntu Issue, not a Gnome issue.
>
And what version of gedit is in Arch?

In any event don't see this changing in 12.04 > 13.04 so users should
live with or find alt. means, - nano, vim, switch to pkexec, a ppa,
ect.(I use pkexec here in 12.04 thru 13.10 with no issue

13.04 users, if inclined, can upgrade to gedit 3.8 in the gnome3 ppa

re: #45

> For that reason, the simplest method is to create a new file (I call it "ggedit"), place it in your path, and make it executable. The file contains just one line:

> gksudo gksudo gedit "${@}"

In Ubuntu not being root, it also makes things easier to chown the file to my username so I don't need to type in "sudo ggedit" just "ggedit"

> … it also makes things easier to chown the file to my username so I don't need to type in "sudo ggedit" just "ggedit"

You don't have to use sudo, regardless of who owns the script. Additionally, you should use gksudo, not sudo — which is already in the one-line script, to save you the trouble of typing it. Just enter "ggedit" by itself.

This version has expired