Weird effect. Trying to modify this command to learn how to assemble a detailed find command;
$ sudo find \/ -type f -executable -readable | tee 0
I have backed up to the \/ in .png to see if this would work. If it did, I was going to see if I could negate the .png and drop them from the final list in 0. But the command fails, And it is not what I entered at all.. And the more I try, the worse it gets. And the corruptions seem to keep incresing with each fresh edit. Here are some pastes of as I kept trying to do this:
$ sudo find \/ .png -type f -executable -readable | tee 0
$ sudo find \/ !.png -type f -executable -readable | tee 0
sudo find \/ find \/ .sh -type f -executable -readable | tee 0.png -type f -executable -readable | tee 0
tee: invalid option -- 't'
Try 'tee --help' for more information.
On pullback: $ sudo find \/ find \/ *.sh -type f -executable -readable | tee 0.png -type f -executable -readable | tee 0
Next attempt in same terminal window, just editing the corrupted puuback:
$ sudo find \/ .png -type f -executable -readable | tee 0; less 0
This time it worked -- sort of. I got some sh files, but the '\/ listing was entirely different. Gone were amny of the text files and instead I saw exe and other file types. Intriqued, I decided to see what would happen if I changed the sh to exe.
$ sudo find \/ .exe -type f -executable -readable | tee 0; less 0
I got a list of lots, incuding exe files, but on quitting less, I got this back from find: `.exe': No such file or directory
Well. I obviously don't really understand find as well as I need to, but I know vommand corruption when it reaches out and bites me.
Anonymous
I think there's a problem when the command is too long to fit on one line and/or either the previous command didn't end with a newline or went into the background and caused more output to appear after the current prompt, so the cursor isn't in its usual position. I think that's a problem with the shell (bash), possibly with vte, but it definitely isn't something roxterm can control.
Make sure the cursor is in its correct position, eg by pressing return, before navigating the history or entering anything else. Also, if you move the cursor backwards and forwards in the corrupted line you'll probably find it redraws those characters with a different offset from the command line, but that can still be confusing, so I always reset it with return first.
If there are non-ASCII characters in the filenames that find outputs, that can "corrupt" the terminal too.