Hide Forgot
Several regressions in the "tcsh" have been fixed This update fixes several regressions in the "tcsh" command language interpreter: * When browsing command history using the `Ctrl+P` or `Up Arrow` keys, backslashes are now shown correctly. * A backslash now correctly escapes user-defined aliases; this fixes git-completion. * The output of the built-in "time" command is now correctly captured when used with the built-in "setenv" command.
This is also present in RHEL-6, since tcsh-6.17-35.el6: +++ This bug was initially created as a clone of Bug #1333523 +++ Description of problem: If a command has a backslash within quotes, and that command is brought back with e.g. "up-history", the backslash is doubled. Version-Release number of selected component (if applicable): tcsh-6.19.00-7.fc24.x86_64 How reproducible: Every time Steps to Reproduce: 1. echo '\n' 2. <Up> (or ctrl-p) Actual results: The line says: echo '\\n' Expected results: A line saying: echo '\n' --- Additional comment from Kamil Dudka on 2016-05-06 10:07:46 CEST --- I am able to reproduce it on f23 if I just compile the f24 version of tcsh: kdudka@f23 ~/fedora/tcsh/tcsh-6.19.00 $ ./tcsh [kdudka@f23 tcsh-6.19.00]$ echo '\n' [kdudka@f23 tcsh-6.19.00]$ echo '\\n' After commenting out tcsh-6.19.00-026-quote-backslashes-properly.patch, the bug is no longer reproducible: kdudka@f23 ~/fedora/tcsh/tcsh-6.19.00 $ ./tcsh [kdudka@f23 tcsh-6.19.00]$ echo '\n' [kdudka@f23 tcsh-6.19.00]$ echo '\n' --- Additional comment from David Kaspar [Dee'Kej] on 2016-05-10 14:50:10 CEST --- I have already informed upstream about this: http://mx.gw.com/pipermail/tcsh-bugs/2016-May/001043.html --- Additional comment from David Kaspar [Dee'Kej] on 2016-05-10 14:54 CEST --- The patch seems to be an EasyFix (one liner). It fixes the regression, testsuite passes, as well as the testcase for the initial issue.
Supreet has found another issue related to this: ------------------------------------------------ On RHEL 6.7 : [root@localhost ~]# set myvar = `\echo "1 2 3"` [root@localhost ~]# echo ${myvar} 1 2 3 [root@localhost ~]# echo ${myvar[1]} 1 [root@localhost ~]# echo ${myvar[2]} 2 [root@localhost ~]# echo ${myvar[3]} 3 [root@localhost ~]# echo ${myvar[3]} 3 [root@localhost ~]# echo $SHELL /bin/tcsh [root@localhost ~]# On RHEL 6.8 : [root@vm6 ~]# set myvar = `\echo "1 2 3"` [root@vm6 ~]# echo ${myvar} 1 2 3 [root@vm6 ~]# echo ${myvar[1]} 1 2 3 [root@vm6 ~]# echo ${myvar[2]} myvar: Subscript out of range. [root@vm6 ~]# echo $SHELL /bin/tcsh [root@vm6 ~]# This gives the correct behaviour set myvar = `echo "1 2 3"` But this doesn't in 6.8 set myvar = `\echo "1 2 3"` I found these comments in the change log, it looks like it did more then preserving the backslash. - quote backslashes properly to preserve them in `...` expressions Resolves: #1301857 The real reason I came across this issue, is that there is a widely distributed setup for shell completion support for git that fails with the 6.8 tcsh. https://github.com/git/git/blob/master/contrib/completion/git-completion.tcsh This is the code... set __git_tcsh_completion_version = `\echo ${tcsh} | \sed 's/\./ /g'` if ( ${__git_tcsh_completion_version[1]} < 6 || \ ( ${__git_tcsh_completion_version[1]} == 6 && \ ${__git_tcsh_completion_version[2]} < 16 ) ) then echo "git-completion.tcsh: Your version of tcsh is too old, you need version 6.16.00 or newer. Git completion will not work." exit endif -------------------------- I have already informed upstream about this: http://mx.gw.com/pipermail/tcsh-bugs/2016-May/001049.html
Upstream has already fixed the regression, here is the commit: https://github.com/tcsh-org/tcsh/commit/819ab9146f10a3
*** Bug 1347237 has been marked as a duplicate of this bug. ***
I have closed this by mistake (thought this was fixed in RHEL 6.7.z), reopening...
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0731.html