Version: (using KDE KDE 3.5.6) Installed from: Fedora RPMs OS: Linux When started from command line, kpdf does not open a file whose name contains no path elements and contains a colon. No error message (such as "Could not open ...") is displayed. The window title contains the filename part after the colon. If I do: [in /tmp, given a file named '/tmp/windows:200.pdf'] kpdf windows:200.pdf I see: kpdf starts, no document is opened, no error message, the title says "200.pdf" I expected: kpdf should open "/tmp/windows:200.pdf" (or kpdf should display an error message, see notes below for why) The following commands work, though: kpdf /tmp/windows:200.pdf kpdf ./windows:200.pdf kpdf file:///tmp/windows:200.pdf kpdf file:///tmp/windows%3a200.pdf Notes: - If the colon is the first character, kpdf works as usual (that is, it opens ':13.pdf') - The part before the colon can be anything (even 'http'). - This bug might be related to Bug #111760 ("colon in filenames causes problems", reported for kuickshow). The bug report says that kde expects a protocol name in front of the colon. Although I think kpdf should open the file anyways (as 'windows' is not a protocol, nor is the filename a valid URI), if there is no such protocol or file, kpdf should at least print an error message (such as "Could not open file 'http:13.pdf').
SVN commit 669593 by dfaure: Reworked KCmdLineArgs::makeURL to make "kpdf a:b" work when a:b is an existing file in the current directory CCBUGS: 111760, 146105 Albert will backport to 3.x M +14 -13 kernel/kcmdlineargs.cpp M +8 -0 tests/kcmdlineargstest.cpp --- trunk/KDE/kdelibs/kdecore/kernel/kcmdlineargs.cpp #669592:669593 @@ -1331,21 +1331,22 @@ KUrl KCmdLineArgs::makeURL(const char *_urlArg) { - QString urlArg = QFile::decodeName(_urlArg); - if (!QDir::isRelativePath(urlArg)) - { - KUrl result; - result.setPath(urlArg); - return result; // Absolute path. - } + const QString urlArg = QFile::decodeName(_urlArg); + QFileInfo fileInfo(urlArg); + if (!fileInfo.isRelative()) { // i.e. starts with '/', on unix + KUrl result; + result.setPath(urlArg); + return result; // Absolute path. + } - if ( !KUrl::isRelativeUrl(urlArg) ) - return KUrl(urlArg); // Argument is a URL + if ( KUrl::isRelativeUrl(urlArg) || fileInfo.exists() ) { + KUrl result; + result.setPath( cwd()+'/'+urlArg ); + result.cleanPath(); + return result; // Relative path + } - KUrl result; - result.setPath( cwd()+'/'+urlArg ); - result.cleanPath(); - return result; // Relative path + return KUrl(urlArg); // Argument is a URL } void --- trunk/KDE/kdelibs/kdecore/tests/kcmdlineargstest.cpp #669592:669593 @@ -83,6 +83,14 @@ kDebug() << u << endl; assert(u.url() == "http://www.kde.org"); + QFile file("a:b"); + bool ok = file.open(QIODevice::WriteOnly); + assert(ok); + u = KCmdLineArgs::makeURL("a:b"); + qDebug() << u.path(); + assert(u.isLocalFile()); + assert(u.path().endsWith("a:b")); + args->clear(); // Free up memory.
SVN commit 669594 by aacid: backport SVN commit 669593 by dfaure: Reworked KCmdLineArgs::makeURL to make "kpdf a:b" work when a:b is an existing file in the current directory BUGS: 111760, 146105 M +10 -9 kcmdlineargs.cpp --- branches/KDE/3.5/kdelibs/kdecore/kcmdlineargs.cpp #669593:669594 @@ -1248,21 +1248,22 @@ KURL KCmdLineArgs::makeURL(const char *_urlArg) { - QString urlArg = QFile::decodeName(_urlArg); - if (!QDir::isRelativePath(urlArg)) - { + const QString urlArg = QFile::decodeName(_urlArg); + QFileInfo fileInfo(urlArg); + if (!fileInfo.isRelative()) { // i.e. starts with '/', on unix KURL result; result.setPath(urlArg); return result; // Absolute path. } - if ( !KURL::isRelativeURL(urlArg) ) - return KURL(urlArg); // Argument is a URL + if ( KURL::isRelativeURL(urlArg) || fileInfo.exists() ) { + KURL result; + result.setPath( cwd()+'/'+urlArg ); + result.cleanPath(); + return result; // Relative path + } - KURL result; - result.setPath( cwd()+"/"+urlArg ); - result.cleanPath(); - return result; // Relative path + return KURL(urlArg); // Argument is a URL } void
*** Bug 147808 has been marked as a duplicate of this bug. ***
Is this fix was included in KDE 3.5.7?
No, it will be in KDE 3.5.8, in case it is released.