Bug 276103

I can reproduce this with dolphin-1.7 and gedit-3.2.1. This problem is actually quite easy to reproduce.

"kioclient exec sample.txt" gets the same result, so the real problem is not in dolphin.

There is some discussion here: https://bbs.archlinux.org/viewtopic.php?id=120283

Looks like related with gedit's feature of acepting data from pipe.

FYI, I can't reproduce this problem any more using kdelibs built from master branch

*** Bug 307624 has been marked as a duplicate of this bug. ***

This solution solved it for me on Dolphin:
http://forums.linuxmint.com/viewtopic.php?f=190&t=96040&p=560682#p550417

Actually, the above fixed it with me in Dolphin and gedit, also gedit will open fine if activated from a terminal window, but the above change will then open three tabs up for me named $, <, and null if I try to open the file from Nautilus.  I was using Dolphin in GNOME to avoid some shortcomings in Nautilus but I guess it's difficult to find a solution for all three in GNOME.

One possibility for me (I'll have to look into it), is keep the gedit configuration as-is so it will work w/command-line & Nautilus but have dolphin open another application that does the $1 < dev/null change, as discussed here:  http://newton.freehostia.com/comp/ubstuff.html

OK, I got it to work, I use gedit as normal for Nautilus and when activating from the command-line.  For Dolphin, I created a wrapper (I called it "kdegedit" but it can be called anything that doesn't conflict with another app name) of gedit in /usr/loca/bin and configured dolphin to use that wrapper instead of gedit as described here: http://forums.linuxmint.com/viewtopic.php?f=190&t=96040&p=560682#p550417 , except instead of configuring Dolphin to use gedit $1 < dev/null I configured it as kdegedit %u.  Then in Dolphin make sure gedit is removed as the default viewing app for any type of file, replaced with kdegedit instead.

gmazza@gmazza-work:/usr/local/bin$ ls -la
total 12
drwxr-xr-x  2 root root 4096 Oct  1 08:27 .
drwxr-xr-x 10 root root 4096 Apr 25 12:04 ..
-rwxrwxrwx  1 root root   36 Oct  1 08:27 kdegedit

(make sure you have the permissions like above so non-root can use it)

gmazza@gmazza-work:/usr/local/bin$ more kdegedit
#!/bin/bash
gedit "$1" < /dev/null

Workaround working for me with Dolphin, Nautilus, and Konqueror in KDE:

1. Open file .local/share/applications/gedit.desktop or /usr/share/applications/gedit.desktop
2. Search  the line beginning with "Exec=", and replace it with:
  Exec=bash -c 'gedit "$@" < /dev/null' - %U

I think Nautilus interprets the command "gedit $1 < dev/null" as stated in http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables . It doesn't executes the command in a shell environment (like dolphin does), but runs it by "itself".
The new command creates the needed shell environment for Nautilus, so that it can be used for all three file managers.

*** Bug 325389 has been marked as a duplicate of this bug. ***

I just stumbled over this bug report and decided to add a comment because I have seen the same problem in the past. (I never bothered much about it because I don't use gedit anyway. I prefer KWrite/Kate by far... ;-) )

I cannot reproduce this problem any more here on openSUSE 13.1 with KDE 4.12.3 and gedit 3.10.3, if I right-click on a text file and select Open with->gedit, only the text file is opened, there is no second empty tab in gedit. And the same is also true when I left-click on a file associated with gedit.

I tried on a fresh openSUSE 12.3 installation (KDE 4.10.0 and gedit 3.6.2) and there the problem occurs as described in this bug report: gedit also opens a second empty tab (named "Unsaved Document 1"), and asks if the changes in that second tab should be saved when I quit it.
But: After upgrading gedit to 3.8.3, the problem disappeared! (with the same KDE version)

Since I haven't ever seen a similar problem with any other application, I tend to believe this was actually a bug in gedit that apparently got fixed in its 3.8 incantation.

Based on my observations, I would say that this bug report can/should be closed.

Thanks Wolfgang for the analysis. Let's close this then.