Menu
▾
▴
gnuplot-info
|
From: Jon <dev...@gm...> - 2010-09-25 20:24:10
|
Dear All, I had raised this issue some time ago, but was persuaded that it could be due to the operation system setting instead of gnuplot itself. Since I am not very familiar with the linux system on my local computer, I gave it up as it is. Now, I tried to use putty (with -X option on) to connect to a remote computer and run gnuplot there. The remote linux system can correctly respond to the keys of insert, delete, home, end etc, but when I get into gnuplot, these keys cannot be recognized. For example, insert is shown as 2~, delete is shown as 3~ .... Any idea on what could be the reason? Thanks for helping me out on this issue Sincerely, John |
|
From: Johannes R. <ja...@ho...> - 2010-09-25 22:52:43
|
It sounds to me as if your version of gnuplot is not compiled with readline support. readline is the library which is responsible for all the nice editing features, including the history and the key bindings. Did you compile gnuplot yourself? Am 25.09.2010 22:24, schrieb Jon: > Dear All, > > I had raised this issue some time ago, but was persuaded that it could be > due to the operation system setting instead of gnuplot itself. Since I am > not very familiar with the linux system on my local computer, I gave it up > as it is. > > Now, I tried to use putty (with -X option on) to connect to a remote > computer and run gnuplot there. The remote linux system can correctly > respond to the keys of insert, delete, home, end etc, but when I get into > gnuplot, these keys cannot be recognized. For example, insert is shown as > 2~, delete is shown as 3~ .... Any idea on what could be the reason? > > Thanks for helping me out on this issue > > Sincerely, > John > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > gnuplot-info mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-info > > |
|
From: Jon <dev...@gm...> - 2010-09-26 04:54:20
|
Thanks, I would guess the same on my local computer. I let it installed by ubuntu itself. I have no idea on how it is actually carried out. But for this remote computer, I would trust that the administrator(my friend and is very good at linux, but I cannot reach him these days) has done it to perfection. That could be too arrogant, here are some facts I noticed, don't know whether these are only provided by readline support it can copy and paste as usual, it responds well to arrow up/down/left/right, it has .gnuplot_history at user's home directory. I never tried key bindings, so I don't know that. On Sat, Sep 25, 2010 at 5:53 PM, Johannes Rauh <ja...@ho...> wrote: > > It sounds to me as if your version of gnuplot is not compiled with > readline support. readline is the library which is responsible for all > the nice editing features, including the history and the key bindings. > > Did you compile gnuplot yourself? > > Am 25.09.2010 22:24, schrieb Jon: > > Dear All, > > > > I had raised this issue some time ago, but was persuaded that it could be > > due to the operation system setting instead of gnuplot itself. Since I am > > not very familiar with the linux system on my local computer, I gave it > up > > as it is. > > > > Now, I tried to use putty (with -X option on) to connect to a remote > > computer and run gnuplot there. The remote linux system can correctly > > respond to the keys of insert, delete, home, end etc, but when I get into > > gnuplot, these keys cannot be recognized. For example, insert is shown as > > 2~, delete is shown as 3~ .... Any idea on what could be the reason? > > > > Thanks for helping me out on this issue > > > > Sincerely, > > John > > > ------------------------------------------------------------------------------ > > Start uncovering the many advantages of virtual appliances > > and start using them to simplify application deployment and > > accelerate your shift to cloud computing. > > http://p.sf.net/sfu/novell-sfdev2dev > > _______________________________________________ > > gnuplot-info mailing list > > gnu...@li... > > https://lists.sourceforge.net/lists/listinfo/gnuplot-info > > > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > gnuplot-info mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-info > |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-09-25 23:03:08
|
On 25.09.2010 22:24, Jon wrote: > I had raised this issue some time ago, but was persuaded that it could be > due to the operation system setting instead of gnuplot itself. It is. It's regularly caused by a mismatch of the character encoding used by the terminal (emulator) and the terminal setting. Double-check your TERM environment variable, gnuplot build options (readline or not), and the settings of your terminal emulator (PuTTY in your case). |
|
From: Jon <dev...@gm...> - 2010-09-26 04:59:23
|
2010/9/25 Hans-Bernhard Bröker <HBB...@t-...> > On 25.09.2010 22:24, Jon wrote: > > I had raised this issue some time ago, but was persuaded that it could be >> due to the operation system setting instead of gnuplot itself. >> > > It is. It's regularly caused by a mismatch of the character encoding used > by the terminal (emulator) and the terminal setting. Double-check your TERM > environment variable, gnuplot build options (readline or not), and the > settings of your terminal emulator (PuTTY in your case). > This could be the case as well. The laptop I am using is lenovo x61s. The whole keyboard is separated into several "isolated" parts. The misfunctioning keys are separated from the character keys and are located on the very upper part of the keyboard. So, it could send some unusual character encoding. The reason I didn't doubt this too much is that these unusual character keys(if there were) can be correctly interpreted by the remote computer's linux system. So, why not within gnuplot? Please let me know how to check "TERM environment variable, gnuplot build options (readline or not), and the settings of your terminal emulator (PuTTY in your case)" I am not familiar with these things, thank you very much for your kind help. |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-09-26 11:09:26
|
On 26.09.2010 06:59, Jon wrote: > This could be the case as well. The laptop I am using is lenovo x61s. > The whole keyboard is separated into several "isolated" parts. The > misfunctioning keys are separated from the character keys and are > located on the very upper part of the keyboard. It's pretty much impossible that that would have anything to do with the problem. This is happening several layers of software away from the physical buttons. > Please let me know how to check "TERM environment variable, gnuplot > build options (readline or not), and the settings of your terminal > emulator (PuTTY in your case)" I am not familiar with these things, > thank you very much for your kind help. For starters, inspect all settings of PuTTY in the "Terminal" folder of the options dialog, and do a ! echo $TERM in your remote gnuplot session (or just echo $TERM directly in the remote shell, before starting gnuplot). |
|
From: Jon <dev...@gm...> - 2010-09-26 20:00:15
|
2010/9/26 Hans-Bernhard Bröker <HBB...@t-...> > On 26.09.2010 06:59, Jon wrote: > >> This could be the case as well. The laptop I am using is lenovo x61s. >> The whole keyboard is separated into several "isolated" parts. The >> misfunctioning keys are separated from the character keys and are >> located on the very upper part of the keyboard. >> > > It's pretty much impossible that that would have anything to do with the > problem. This is happening several layers of software away from the > physical buttons. Thanks, this reassures me! > > > Please let me know how to check "TERM environment variable, gnuplot >> build options (readline or not), and the settings of your terminal >> emulator (PuTTY in your case)" I am not familiar with these things, >> thank you very much for your kind help. >> > > For starters, inspect all settings of PuTTY in the "Terminal" folder of the > options dialog, and do a > > ! echo $TERM > > in your remote gnuplot session (or just > > echo $TERM > > directly in the remote shell, before starting gnuplot). > For the putty setting, go from putty -> change setting -> terminal -> keyboard, there are a lot of options and I list them here Change the sequences sent by: The Backspace key -- Control+?(127) The Home and end key -- Standard The Function keys and keypad -- ESC(n~ Application keypad setting: initial state of cursor keys: -- Normal Initial state of numerical keypad -- Normal Enable extra keyboard setting: Control+Alt is different from AltGr ------------------------ For your information, I also list choices in putty -> change setting -> terminal, Set various terminal options (checked) Auto wrap mode initially on Use background color to erase screen Answerback to ^E: -- putty Line discipline options: Local echo -- Auto Local line editing -- Auto ------------- There are several options for the three items, I tried to modify to other options, but does not help in gnuplot, the keys changed from 1~ to wH etc. For the command "echo $TERM" running on the remote computer, it returns xterm. The version of putty I used is 0.60 with Cyg enhanced, that is, it is puttyCyg Thanks for further help! |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-09-27 12:53:21
|
On 26.09.2010 22:00, Jon wrote: > 2010/9/26 Hans-Bernhard Bröker<HBB...@t-...> >> On 26.09.2010 06:59, Jon wrote: > For the putty setting, go from putty -> change setting -> terminal -> > keyboard, there are a lot of options and I list them here > > Change the sequences sent by: > The Backspace key -- Control+?(127) You'll probably want to change that to Ctrl-H. > The Home and end key -- Standard > The Function keys and keypad -- ESC(n~ Note that setting: it's showing right the kind of escape sequence that ends up on screen in your gnuplot session, doesn't it? So either you need to change this, or you need to change your Linux session's configuration to match it. That's where TERM comes in. > Application keypad setting: > initial state of cursor keys: -- Normal > Initial state of numerical keypad -- Normal These mean your X11 terminal must _not_ be in "Application cursor keys" mode. > For the command "echo $TERM" running on the remote computer, it returns > xterm. Then you should probably be using Linux or XTerm R6 for the function key setting. > The version of putty I used is 0.60 with Cyg enhanced, that is, it is > puttyCyg That may add new layers to the problem. You may be better off trying off the original PuTTY. |
|
From: Jon <dev...@gm...> - 2010-09-27 20:44:04
|
Thanks, I tried the different options, and followed your suggestions, but they do not work out .. I think I will give up seeking a solution for this issue for the time being and feel comfortable with what gnuplot brings me 2010/9/27 Hans-Bernhard Bröker <HBB...@t-...> > On 26.09.2010 22:00, Jon wrote: > >> 2010/9/26 Hans-Bernhard Bröker<HBB...@t-...> >> >>> On 26.09.2010 06:59, Jon wrote: >>> >> > For the putty setting, go from putty -> change setting -> terminal -> >> keyboard, there are a lot of options and I list them here >> >> Change the sequences sent by: >> The Backspace key -- Control+?(127) >> > > You'll probably want to change that to Ctrl-H. > > > The Home and end key -- Standard >> The Function keys and keypad -- ESC(n~ >> > > Note that setting: it's showing right the kind of escape sequence that ends > up on screen in your gnuplot session, doesn't it? > > So either you need to change this, or you need to change your Linux > session's configuration to match it. That's where TERM comes in. > > > Application keypad setting: >> initial state of cursor keys: -- Normal >> Initial state of numerical keypad -- Normal >> > > These mean your X11 terminal must _not_ be in "Application cursor keys" > mode. > > > For the command "echo $TERM" running on the remote computer, it returns >> xterm. >> > > Then you should probably be using Linux or XTerm R6 for the function key > setting. > > > The version of putty I used is 0.60 with Cyg enhanced, that is, it is >> puttyCyg >> > > That may add new layers to the problem. You may be better off trying off > the original PuTTY. > |
