Version: (using KDE KDE 3.5.8) Installed from: Debian testing/unstable Packages Both /pathwithoutspace/foo.{jpg,txt} and /path with space/foo.{jpg,txt} must exist. kolourpaint /pathwithoutspace/foo.jpg works, while kolourpaint "/path with space/foo.jpg" kolourpaint '/path with space/foo.jpg' do not work, loading an empty foo.jpg. The KDE4 version is not affected and kolourpaint 3.5.8 in a KDE4 session is not affected, either. jstubbs on IRC confirmed that his kwrite shows the same issue, whereas my kwrite is not affected.
On Wednesday 12 December 2007, Richard Hartmann wrote: > kolourpaint "/path with space/foo.jpg" > kolourpaint '/path with space/foo.jpg' > do not work, loading an empty foo.jpg. Can't see that; kolourpaint '/tmp/path with space/2007-12-18.gif' works fine for me. KDE: 3.5.8 KolourPaint: 1.4.7_relight > The KDE4 version is not affected and kolourpaint 3.5.8 in a KDE4 session is not affected, either. How could the session matter, if you're launching kolourpaint from the command line? This report doesn't make sense to me. > jstubbs on IRC confirmed that his kwrite shows the same issue, whereas my kwrite is not affected. Even more strange, isn't it? Either there's some detail missing in this report, or there's some confusion in the testing....
> Can't see that; kolourpaint '/tmp/path with space/2007-12-18.gif' works fine for me. Back when I reported this issue, one person could confirm the bug under KDE 3, another person could not. Even though the two are KDE devs, we were unable to determine what the cause was. One IRC nick was jstubbs and I can find out the other one if need be. If you poke him, he might be able to shed some light onto this. > How could the session matter, if you're launching kolourpaint from the command line? This report doesn't make sense to me. I have been told that this could be an issue with kdeinit, but I am not qualified to venture a guess, myself. I do agree that this sounds strange, though. > Even more strange, isn't it? Either there's some detail missing in this report, or there's some confusion in the testing.... To the best of my knowledge, nothing is missing. The testing consisted of 'run program X with or without whitespace in target file Y's path', so the issue does exist, even though I can not tell you what might be the cause. If you want me to do/run anything to help pinpoint the cause of this problem, please tell me and I will gladly do so.
Jason, any input on this? I cannot reproduce this bug, but apparently you could?
I am back at the machine showing this problem. kolourpaint is version 1.4.8_relight, on this machine.
Cancel my acking. I just tried to reproduce it and couldn't. After going through bash history to find out how I did reproduce it and looking a little bit further, I found that I didn't have permission to access the file I was trying to open - the test file being owned by my kde4 user and 0600. My lack of access permissions (and sleep) causing this problem might help tracking down the problem for Richard though. ;)
I can't promise that I will be able to try again on my own box tonight, but I will do so asap. Up to that time, do you have any suggestions on how to gather additional information when I reproduce this bug?
My suggestions would be to try using tab completion if you aren't already and replacing "kolourpaint" with "ls -l" after a failure. Also, is there a chance that the space is not ascii 32 but some other whitespace? What happens if you drag the file from konqueror to the konsole?
I am not using tab completion, but I did copy & paste the directory after I ran pwd. ls -l is a good idea, but I fear nothing will come of it. As it was pwd output, I don't think it was a non-whitespace nbsp
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Can't reproduce any more.