GNOME Bugzilla – Bug 407945
"GNOME" Terminal" regression after "vte" update when using "csh"
Last modified: 2007-02-16 17:32:30 UTC
Please describe the problem: fter updating to "vte-0.15.3-1.fc7", "GNOME" Terminal" shows some dysfunctional behaviour when "csh" is chosen: control characters for "bold" mode stop working; so do several non-alphanumeric keys such as "tab" and arrow keys. Consequently, file completion or command history are not available anymore. Steps to reproduce: 1. Upgrade to "vte-0.15.3-1.fc7". 2. Open a new "GNOME" terminal window. 3. Try tab-completion, history function, etc. Actual results: Respective features do not work. Expected results: Respective features should continue to work as they did before. Does this happen every time? Yes. Other information: Afer switching to "sh/bash", things work as expected. Likewise, downgrading to "vte-0.15.2-1.fc7" allows to restore full functionality. I have made sure that the issue described above is not due to my ".cshrc" file by moving it away from my home directory.
I'm not a csh user, so...: can you tell us how you test that control characters for bold stop working, etc?
I've just tried tcsh (6.14.00) and tab-completion, with an underlined and bold prompt, works here. Can you use script to record your tcsh session, and a screenshot may help diagnose the renderering problems.
(In reply to comment #1) The corresponding control characters are "%B" and "%b" which I use in my ".cshrc" to output bold characters. I should add however, that e.g. "ls" still uses bold characters for directories even for version "0.15.3" whereas my shell prompt is not printed using bold characters anymore. The main loss is functionality is anyway related to the arrow and "tab" keys which have stopped being translated correctly. I guess you have "tcsh" installed on your system, so you can veryify the latter immediately [for "Fedora" systems, "csh" and "tcsh" are equivalent, and indeed, I should have rather referred to "tcsh" in the first place, because plain "csh" does not have tab-completion etc. at all]. My "tcsh" version is "Fedora" package release "tcsh-6.14-14". Btw, I first reported the issue downstream as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228724
Err, I meant to refer to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228720
Can you attach the relevant part of your .cshrc? How did you test that it is not your cshrc that causes this, as you mentioned above?
Created attachment 82555 [details] Bold prompt and tab-completion using w/vte 0.51.2 Opening a "GNOME" terminal after moving my ".cshrc" out of the way. I define a bold prompt and apply it. It actually works for version 0.15.2. After typing "ls vt" and "tab", the directory name gets correctly completed to "vte/" as shown in the screenshot.
Created attachment 82556 [details] Bold prompt and tab-completion failure using w/vte 0.15.3 Opening a "GNOME" terminal after moving my ".cshrc" out of the way. I define a bold prompt and apply it. It actually does not work for version 0.15.3. After typing "ls vt" and "tab", the directory name "vte/" does not get completed. The cursor simply jumps one tab position to the right. After typing "ctrl-c", pressing the "arrow up" button does not redisplay the last comand but instead issues "^[[A" as shown in the screenshot.
Created attachment 82557 [details] "C" shell skeleton configuration file from "Fedora" development package "setup-2.6.2-1.fc7.noarch"
In case of need, I can attach any of the following files in "/etc/profile.d" referenced by "/etc/csh.cshrc" colorls.csh* gnome-ssh-askpass.csh* krb5-workstation.sh* vim.csh* colorls.sh* gnome-ssh-askpass.sh* lang.csh* vim.sh* cvs.sh* krb5-devel.csh* lang.sh* which-2.sh* glib2.csh krb5-devel.sh* less.csh* glib2.sh krb5-workstation.csh* less.sh*
From the screenshots, I see that you recorded the scripts, could you please attach those as well.
Created attachment 82595 [details] Sample "typescript" file for "vte-0.15.2"
Created attachment 82596 [details] Sample "typescript" file for "vte-0.15.3"
Hmm, so tcsh doesn't output any controls to change the text colour under vte-0.15.3. I can replicate this by unsetting the TERM env variable. I suspect the fiddling with environ+g_spawn has another victim. :-( Can you post the output of env under vte 0.15.2 and 0.15.3? Thanks.
vte 0.15.2: printenv TERM -> xterm vte 0.15.3: printenv TERM -> dumb Ok, after setting "setenv TERM xterm", everythings returns to normal operation.
Created attachment 82651 [details] [review] Replace existing env. variables with the app's. This patch removes any ambiguity in the env we pass down to g_spawn. Joachim, can you apply it and see if it corrects the child environment for you? Thanks.
The patch is for resolving the fact that the envp passed to _vte_pty_run_on_pty might collide with the one in the apps environment? Something like this might prove more legible: void collect_variables (const char *name, const char *value, GPtrArray *array) { char *text; text = g_strdup_printf ("%s=%s", name, value); g_ptr_array_add (array, text); } ... char **var; char *name, *value; GPtrArray *array; table = g_hash_table_new_full (g_str_hash, g_str_equal, g_free, g_free); for (var = environ; *var; var++) { name = g_strdup (*var); value = strchr(name, '='); *value = '\0'; value++; g_hash_table_insert (table, name, value); } for (var = other_environ; *var; var++) { name = g_strdup (*var); value = strchr(name, '='); *value = '\0'; value++; g_hash_table_insert (table, name, value); } array = g_ptr_array_new (); g_hash_table_foreach (table, (GHFunc) collect_variables, array); child_environ = g_ptr_array_free (array, FALSE); /* use child_environ to spawn the child */
*** Bug 408112 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > The patch is for resolving the fact that the envp passed to _vte_pty_run_on_pty > might collide with the one in the apps environment? Originally vte just used putenv(), with no clearenv(), to add the apps environment to the child [which wasn't a semantic I was expecting and overlooked]. Yes, Mariano that is a little clearer - I just knew someone was going to object to performing O(nm) strcmps ;)
(In reply to comment #15) > Created an attachment (id=82651) [edit] > Replace existing env. variables with the app's. Very good. I have rebuilt "vte-0.15.3-1.fc7" after adding your patch, and it works correctly with respect to the malfunction reported above.
Created attachment 82663 [details] [review] Replace environ with apps Following Mariano's suggestion, this is a cleaner version. Please can you check it still fixes this regression. Thanks.
It does, and it seems to work even better than the old one. I have had the impression that "ctrl-c" was not working correctly with the initial patch.
Thanks Joachim for your help in testing the various patches and persistence in debugging. r1690: 2007-02-16 Chris Wilson <chris@chris-wilson.co.uk> Bug 407945 – "GNOME" Terminal" regression after "vte" update when using "csh" When passing multiple versions of the same environment variable to execve (i.e g_spawn) the result is undefined. So we solve the ambiguity by using the application passed env to override values from the current environment. * src/pty.c: (collect_variables), (merge_environ), (_vte_pty_run_on_pty):
I have checkout HEAD and the lastest is 1691 rev. It solves my problem as well. Thanks!