Bug 224142

Hi, how are you creating the link? I have tried dragging a .pl link onto the desktop to create an icon, and also dragging it into a folderview and chose 'link here' to create a link. Both ways didn't produce any problems, and clicking the resulting link opens the site as expected.

Step to reproduce:
1. Click in folderview area to show popup menu. 
2. Select "Create New" > "Link to location"
3. In text field "File name" type onet.pl
In text field "Enter link to location (URL)" type www.onet.pl
4. Click on created link.

this sounds like more a bug of KUrl or KRun?

Confirmed. I think the file type detection optimization for local files is what causes the issue of the file being detected as a perl script. IOW, it sees the .pl extension and assumes it is a perl script file.

Confirmed, i can reproduce it on KDE 4.7.2
After i create link from context menu of www.onet.pl when i click on it, it`s open with kate & contains:

[Desktop Entry]
Icon=
Type=Link
URL[$e]=www.onet.pl

On file properties: Perl script

Git commit 7f70b65107e5ffa2f33aa443ddb1cfa61a6f11f6 by Dawit Alemayehu.
Committed on 12/01/2012 at 01:19.
Pushed by adawit into branch 'KDE/4.8'.

Filter user input when creating a link to URL locations

M  +15   -2    kfile/knewfilemenu.cpp

http://commits.kde.org/kdelibs/7f70b65107e5ffa2f33aa443ddb1cfa61a6f11f6

A file called .pl is a perl script, this is mandated by the shared-mime-info freedesktop specification (*). IMHO this is a feature, not a bug, here's the reasoning why:

* When determining the type of a file, we can either use the extension or the contents.
* Determination from the contents is slower and in general more fragile (e.g. there are many case of detection going wrong, like text files with C++/Java-looking words, or MSWord files without magic at a fixed position, and so on).
* Determination from the extension gives control to the user.
* So the spec says: use the extension when it's known and unambiguous (not associated with multiple mimetypes), and otherwise fall back to contents.

This way, if contents-based detection goes wrong, the user can override it by giving an explicit extension to the file.

This bug report is about the opposite case, where extension-based detection goes wrong. Well, this is easy to fix: append .desktop to the file name. I suppose the code in knewfilemenu.cpp could do that, although since nowadays the .desktop extension isn't magically hidden on the desktop, it might be a bit of visual clutter for a rare case... ah here's an idea: the code could do a mimetype determination, and append ".desktop" only if the mimetype found was not application/x-desktop.

(*) http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-0.18.html#id2554407

Git commit bb1b0c92a5911bfa47ecb209ad3402f0ca98c4cb by Dawit Alemayehu.
Committed on 13/01/2012 at 20:00.
Pushed by adawit into branch 'KDE/4.8'.

Append ".desktop" to generated link files so that they are not identified as
something they are not.
FIXED-IN: 4.8.0
REVIEW: 103691

M  +6    -0    kfile/knewfilemenu.cpp

http://commits.kde.org/kdelibs/bb1b0c92a5911bfa47ecb209ad3402f0ca98c4cb

Git commit 2315781db5ba5d6c24aa7df02b4aeb009bd78188 by Sebastian Trueg, on behalf of Dawit Alemayehu.
Committed on 12/01/2012 at 01:19.
Pushed by trueg into branch 'KDE/4.8'.

Filter user input when creating a link to URL locations

M  +15   -2    kfile/knewfilemenu.cpp

http://commits.kde.org/kdelibs/2315781db5ba5d6c24aa7df02b4aeb009bd78188

Git commit 74bc2eeaa89f5c049469439be67f40feadab7f2a by Sebastian Trueg, on behalf of Dawit Alemayehu.
Committed on 13/01/2012 at 20:00.
Pushed by trueg into branch 'KDE/4.8'.

Append ".desktop" to generated link files so that they are not identified as
something they are not.
FIXED-IN: 4.8.0
REVIEW: 103691

M  +6    -0    kfile/knewfilemenu.cpp

http://commits.kde.org/kdelibs/74bc2eeaa89f5c049469439be67f40feadab7f2a

Git commit 1775292fbd429a9e07dc9d612f2ea0b0afcc2541 by David Faure.
Committed on 09/03/2012 at 23:53.
Pushed by dfaure into branch 'KDE/4.8'.

New File menu: fix regression due to overzealous name-fixup code.

The fix for bug 224142 ended up affecting other file types than desktop
files, and appending ".desktop" to these.
Fixed by making the extension-appending code more generic, which fixes
the similar issue with normal files too: e.g. naming a text file
"foo.jpg" will end up creating a file named "foo.jpg.txt"

With unittest so that this won't happen again :)
Related: bug 295490
FIXED-IN: 4.8.2

M  +15   -9    kfile/knewfilemenu.cpp
M  +1    -0    kfile/tests/CMakeLists.txt
A  +115  -0    kfile/tests/knewfilemenutest.cpp     [License: LGPL (v2/3+eV)]

http://commits.kde.org/kdelibs/1775292fbd429a9e07dc9d612f2ea0b0afcc2541