I just noticed a little quirk with the "Follow path of current file" option for VTE.
Consider this... 1. Open a file in your $HOME directory. 2. Open another file from some other directory. 3. In vte, type "echo" followed by a space, but don't press return. 4. Click the on the tab of the first file you opened.
The resulting command is "echo cd /home/username"
Now imagine if you had typed "rm -rf " instead of "echo "
Yikes!
Maybe it would be safer to only issue the cd command if there is no other text on the command line. I skimmed through the vte headers and the only thing I see that might work is to call vte_terminal_get_cursor_position() first, and check to make sure the column value is zero.
- Jeff
On Tue, 4 Dec 2007 16:16:34 -0600, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
I just noticed a little quirk with the "Follow path of current file" option for VTE.
Consider this...
- Open a file in your $HOME directory.
- Open another file from some other directory.
- In vte, type "echo" followed by a space, but don't press return.
- Click the on the tab of the first file you opened.
The resulting command is "echo cd /home/username"
Now imagine if you had typed "rm -rf " instead of "echo "
It's getting really funny if the path of the file is "/" ;-).
Maybe it would be safer to only issue the cd command if there is no other text on the command line. I skimmed through the vte headers and the only thing I see that might work is to call vte_terminal_get_cursor_position() first, and check to make sure the column value is zero.
Yes but checking the column to zero doesn't help because it isn't at all. But we could keep the cursor position after a sent command(e.g. cd ...) and then compare it to the current cursor position just before sending any command to the VTE. This works in theory, but while testing it I noticed another problem: we send "cd ..." to the VTE using vte_terminal_feed_child() and after that we retrieve the current cursor position. But we get the "old" position because vte_terminal_feed_child() works asynchronously and so the code to retrieve the cursor position is executed before the cd command was actually executed. And I don't see a way to detect when the executed command within the VTE has finished.
The only thing I could imagine is to delay the retrieval of the new cursor position so that we can assume the command has finished. But this is somewhat ugly and may cause other errors. Delaying the cursor position retrieval could work for the "cd" command when switching between tabs but will probably fail when using the Run command in the VTE. Attached is a patch to check for changed cursor positions after a delay of 0.5 seconds. It seems to work for the "cd" command but it breaks the auto path changing feature as well as the ability to run commands in the VTE if one runs an open file in the VTE and the duration of the command is longer than the delay (0.5 seconds). All should work again after the VTE is restarted.
I'm not sure at all whether the way I did it in the patch is good, whether we should it in this way or whether there is any better way(I hope so).
Thanks for reporting, good catch.
Regards, Enrico
On Dec 5, 2007 9:19 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
I'm not sure at all whether the way I did it in the patch is good, whether we should it in this way or whether there is any better way(I hope so).
Here is another idea - This patch issues a {HOME} escape sequence before "typing" the command, and then adds a " #" comment marker after it, so anything already on the command line becomes a comment.
It seems to work for me, but I'm not sure if the "\e[H" escape sequence is valid for all keyboards.
It also won't work unless the {HOME} key is bound to "beginning-of-line" (I assume that it is for most humans).
Note that I only changed for vte_cwd() but the same idea should work also for build_run_cmd() in build.c
- Jeff
On Wed, 5 Dec 2007 12:08:55 -0600, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Dec 5, 2007 9:19 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
I'm not sure at all whether the way I did it in the patch is good, whether we should it in this way or whether there is any better way (I hope so).
Here is another idea - This patch issues a {HOME} escape sequence before "typing" the command, and then adds a " #" comment marker after it, so anything already on the command line becomes a comment.
It seems to work for me, but I'm not sure if the "\e[H" escape sequence is valid for all keyboards.
It also won't work unless the {HOME} key is bound to "beginning-of-line" (I assume that it is for most humans).
Nice idea but doesn't work in zsh and dash (both with default configurations tested on Debian Testing). Additionally, zsh seems to have problems with the '#' in a command: cd /tmp # doesn't work in zsh.
I don't know much about shells(just using bash and being happy ;-)), the manual page for dash doesn't mention any escape sequences at all ;-(.
Just another idea(probably not better): In the key-press event handler we look for any typed characters (or for a changed cursor position) and if found, we mark the VTE as "dirty" so that commands can't be run until the user marked the VTE as clean again (e.g. by restarting it).
Regards, Enrico
On Wed, 5 Dec 2007 20:04:56 +0100, Enrico Tröger enrico.troeger@uvena.de wrote:
Just another idea(probably not better): In the key-press event handler we look for any typed characters (or for a changed cursor position) and if found, we mark the VTE as "dirty" so that commands can't be run until the user marked the VTE as clean again (e.g. by restarting it).
Another way to mark it again as clean could be pressing Enter and Return, so we assume the entered command is executed and we have a clean prompt again.
Regards, Enrico
On Dec 5, 2007 1:11 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
In the key-press event handler we look for any typed characters (or for a changed cursor position) and if found, we mark the VTE as "dirty" so that commands can't be run until the user marked the VTE as clean again (e.g. by restarting it).
That might be the best bet.
Another way to mark it again as clean could be pressing Enter and Return, so we assume the entered command is executed and we have a clean prompt again.
Except if the user is in the middle of a multi-line command ( e.g. echo \ ) But I also notice my patch is won't work for this case either.
As far as the other shells like dash or zsh, I'm not sure how much you can worry with that, since there is no telling what sort of interpreter might be running in the terminal. (Perl,Python,Lua, gdb....)
Maybe for some shell "cd" means "crash drive" ? ;-)
- Jeff
On Wed, 5 Dec 2007 13:29:12 -0600, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Dec 5, 2007 1:11 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
In the key-press event handler we look for any typed characters (or for a changed cursor position) and if found, we mark the VTE as "dirty" so that commands can't be run until the user marked the VTE as clean again (e.g. by restarting it).
That might be the best bet.
I implemented a similar way. The above hadn't recognised things like pasting in the contents of the clipboard. It could have been captured with the paste-clipboard signal but only when using the popup menu, when using Shift-Insert for pasting, the VTE didn't know this. So, I used the VTE commit signal which sets the VTE as not clean, only pressing Enter/Return and the restart of the VTE mark it as clean again. An error message is printed when vte_send_cmd() is called on a non-clean VTE(maybe the message could be improved?).
I hope this will work in all cases, at least it is independent from the shell which is running in the VTE.
Another way to mark it again as clean could be pressing Enter and Return, so we assume the entered command is executed and we have a clean prompt again.
Except if the user is in the middle of a multi-line command ( e.g. echo \ ) But I also notice my patch is won't work for this case either.
Yes, but I don't know how to catch such cases and the user should also take a little care of what he is doing.
Maybe for some shell "cd" means "crash drive" ? ;-)
Hehe, or a bored user define alias cd="rm -rf" I guess somewhere are limits of what we can do to work around user's negligence.
Regards, Enrico