Version: (using Devel) OS: Linux Installed from: Compiled sources KDE has problem with link which ends on .pl (Polish national domain ;) ) After creating shortcut to www.onet.pl or other page, shortcut is treated as perl script. You need to manual change it name to something which doesn't end on .pl Moreover I have noticed that if write url without http:// (just www.onet.pl) shortcut will be opened in kwrite not in firefox.
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