Bug 161637

Uhm, this bug report is wrong. I just didn't press <ENTER> after the rm command. Then browsed to another directory and THEN pressed enter without taking another close look at the terminal. This caused the additional wrong parameters to be added to the command.

dfaure suggested, that the konsole-part could detect if any letters where typed into the window but enter wasn't pressed yet. If that is the case, then it shouldn't paste any "cd ..." or other commands into the window to prevent the described unexpected behaviour.

Created attachment 26331 [details]
Screenshot of Dolphin massacring Fred's files

Why is this marked as solved?  I'm using KDE 4.0.98, and it is still true.

I dare you to do the following:

Navigate to /home/ with Dolphin.  Press F4 to open the built-in console.

Then, enter a command such as the following:

"rm -fr "

At this point you realise you're not in the right directory.  You want to be in
/home/fred/music in order to delete a subdirectory of it.  So, you click on
"fred" and... bye-bye files.  *All* your files.

If you're lucky, you didn't put a space after the "-fr", and you'll just get an
error saying "rm: invalid option -- c".  If you're unlucky, you did put the
space in.

This automatic cd-ing needs to be implemented in a totally different, safer
way.

It still happens in trunk, so this is not resolved. I have r835199 of kdebase and it still happens.

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

Reopened this issue.

Can this be fixed by moving the current command in the terminal ("rm -rf") to another place/variable/buffer, then do the "cd new_directory", and then when you're in the new dir, paste again the ("rm -rf") line in the terminal ? (I'm just talking without knowing :))

I just got bit by this one myself.  I switched tabs to copy a path and sure enough, it ran my incomplete command with "cd" and "$DIR" as arguments.

I suggest:
1) The embedded console be made per-tab rather than per-window.
2) Dolphin send "^Ccd $DIR" to the console rather than simply "cd $DIR".

The Ctrl-C command will cancel the current line and bring up a blank prompt.  If a command is running, it will be aborted.  This is good because it causes the current directory to be changed as expected, and also prevents the "cd $DIR" from being dumped into the current command's stdio (try running "head -n 3" and clicking around).

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

Please set Severity major
because ofPossible data loss
as in dup https://bugs.kde.org/show_bug.cgi?id=183686

Changing severity to major due to possibility of data loss

(In reply to comment #7)
> I suggest:
> 1) The embedded console be made per-tab rather than per-window.
> 2) Dolphin send "^Ccd $DIR" to the console rather than simply "cd $DIR".
> 
> The Ctrl-C command will cancel the current line and bring up a blank prompt. 
> If a command is running, it will be aborted.

I think it would be better if dolphin could recognize what is going on in konsole and send "cd $DIR" when two conditions are met:
 1. synchronizing the working directory is enabled in the settings
    (option like in kate)
 2. the current working directory of konsole is not already the same as in dolphin
 3. there is an _empty_ shell prompt waiting for some input
    (konsole had to be able to detect this)

If this is not possible or to difficult to realize, I suggest
to replace this functionality by a manual action and provide a toolbar button and an entry in the context menu of the embedded konsole.

NB: kate suffers from the same problem.

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

Konsole could pass a ^U, then cd, then a ^Y, which would store the current command in the buffer, cd, then put it back... This, however, would require bash, and clobber anything someone might've had in the buffer.

Dolphin should probably not blindly write to the terminal in any case.

I don't want to test it... but it looks quite dangerous

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

Just got hit by this ! And I was typing "rm -rf"... so I've LOST data but fortunately, I had a backup of this disk (yes it was a whole disk, I was browsing "/media/ExternalUSBDrive/").

I've lost a whole NTFS-formatted disk : it was extremely quick to remove all my files : 1 or 2 secs for more than 8000 files. It's finally a quite efficient file system... to loose all your data.

Testdisk was even unable to undelete the files because it seems they are not deleted the way Windows does it. Photorec is probably able to restore most of the files, but fortunately, I had those backups.

Beware of this dolphin behaviour !!

I've just tried this on a test enviroment (for avoiding to loose files) and the behaviour is completely reproducible on trunk.

This is obviously a real problem and leads to accidental data loss. If there is no immediate solution for this, the feature of automatically sending "cd something" to the terminal should be disabled immediately for the next release in my opinion.

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

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

Just had some incomplete "rsync -av --del" command in the terminal and then clicked on a folder. This caused the command to be executed with wrong arguments.
Luckily I did not lose data on my server, but this is *really* dangerous!

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

I have lost very important data because of that [1], as a lot had changed since the last backup (less than a month old).

So please fix this bug.

[1] Most parts can only be recovered by hand (thx ext4 :/) so I am not finished with the recovering process yet, greping 280 GB for odt files and then checking if they are files at all or the wanted ones is a tedious job. So the amount of real dataloss is still unclear.

This bug report nears it's second birthday. 

In my opinion it would be good to disable or to mitigate the feature of changing dirs in the embedded konsole window.

I think comment #11 made some reasonable suggestions which might work. (I don't know if konsole is able to report if something has been typed already on the prompt).

I'd even agree if someone would state that the whole embedded konsole window feature is not important enough to risk unintendet data loss.

The fact that several ppl reported here shows that it actually happens even to bugtracker-aware "power users".

I'll fix this issue for sure until KDE SC 4.5 gets released. If possible, I'll try to provide already a fix for KDE SC 4.4.x, but cannot promise it.

Glad to hear that. Kudos to you!!

SVN commit 1103207 by ppenz:

Fix issue that the current terminal line does not get cleared before sending a cd command.

The terminal interface does not provide an API for this, so as workaround backspaces are send. Not nice, but as the issue can lead to data loss, this solution is better than having nothing.

BUG: 161637

 M  +35 -13    terminalpanel.cpp  
 M  +10 -3     terminalpanel.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1103207

SVN commit 1103209 by ppenz:

Backport of SVN commit 1103207: Fix issue that the current terminal line does not get cleared before sending a cd command.

The terminal interface does not provide an API for this, so as workaround backspaces are send. Not nice, but as the issue can lead to data loss, this solution is better than having nothing.

CCBUG: 161637

 M  +35 -13    terminalpanel.cpp  
 M  +10 -3     terminalpanel.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1103209

Thank you for the fix. This indeed is better than nothing. Also 255 (256?) backspaces might be enough in most cases, I wonder if it was not more secure to just send one ctrl+c char? Or is this ctrl+c bash-specific? Another possibility (but maybe also shell specific?) might be a ctrl+a and ctrl+k (jump to the beginning of the line and erase the rest of the line beginning from the cursor).

Great! I'd also prefer Ctrl + C if possible, since that way the aborted command would still be listed, though disadvantage in fact would be having "^C" for every cd.

CTRL+C could be an interesting solution: could it works for other shells?

CTRL+c works in sh, zsh and csh as I have tried now, while CTRL+a does not.

Another advantage of ctrl+c versus backspaces is, that multiline inputs are not canceled with backspaces. E.g.

for i in * [RETURN]
echo $i [256x backspace]

SVN commit 1106403 by ppenz:

Send CTRL+C to the terminal instead of of backspaces. Thanks to the FiNeX and g111 for the hint. 

CCBUG: 161637

 M  +5 -6      terminalpanel.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1106403

So if I have some program running in/from Dolphin's terminal, it gets killed when I change the directory?

Well, still far better than loosing data. Thanks for the fix!

It is really astonishing how many situations you have to pay attention to.

I think the best (the safest) solution was to offer a button "cd to current dir" (similiar than the button in kate's filemanager tab where you can switch to the directory of the current edited document). With this button the user does have the control what he is doing. It also might only print the "cd $path" into the shell without the newline character so that the user has to commit the command manually by pressing return.

SVN commit 1107998 by ppenz:

Backport of SVN commit 1106403: Send CTRL+C to the terminal instead of of backspaces. Thanks to the FiNeX and g111 for the hint. 

CCBUG: 161637

 M  +5 -6      terminalpanel.cpp  
 M  +1 -1      terminalpanel.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1107998

What if ^C is not bound to SIGTERM in the shell?  This will still result in data loss.

Why do you not send a SIGTERM signal instead to kill the running process in the shell?

What is the purpose of the 'c'?  It isn't for the Ctrl+C if I understand this.

    cancel.append(QChar(3));
    cancel.append(QChar('c'));

Perhaps,
    cancel.append(QChar(3));
    cancel.append(QChar(10)); // newline

I'm trying to do the same thing for 46233