Description of problem: Behaviour of expansion of multiple filename globs on a commandline has changed in the recent patch (tcsh-6.14-14.el5_4.2). Beforehand, a commandline expansion would fail with "No match" if all of the globs failed. Now if fails if _any_ glob fails. E.g. I have a little script called "lsccode" that boils down to "ls *.c *.cxx *.for". If a directory contains only C code, this script now fails, which is causing a lot of my build scripts to fail. Version-Release number of selected component (if applicable): tcsh-6.14-14.el5_4.2 How reproducible: Always Steps to Reproduce: 1. mkdir tmpdir; cd tmpdir 2. touch tmp.c 3. ls *.c *.cxx Actual results: ls: No match. Expected results: tmp.c Additional info: Note: this affects 64 bit OS (x86_64) as well as 32. This may be related to bug 529425 but has different symptoms and, I think, is more serious.
This problem also effects grep. It causes grep to throw a backreference error whenever a wildcard is used in the grep command. How reproducible: Always Steps to Reproduce: 1. echo 'abc1' > test.txt 2. grep 'abc1' *.txt Actual Results: grep: Invalid back reference Expected Results: test: abc1 Additional info: When you do not use a wildcard grep functions as expected: grep 'abc1' test.txt abc1 It looks like including the wildcard causes tcsh to see the 1 as a \1
(In reply to comment #0) > Behaviour of expansion of multiple filename globs on a commandline > has changed in the recent patch (tcsh-6.14-14.el5_4.2). Beforehand, > a commandline expansion would fail with "No match" if all of the > globs failed. Now if fails if _any_ glob fails. I am seeing the same problem. My sysadmin upgraded to tcsh-6.14-14.el5_4.2 a few days ago and I just ran the new version for the first time this morning. Immediately all my tcsh configuration files started failing because they depended on the documented behavior of tcsh that no-glob errors are only reported if all globs in the command do not match. > This may be related to bug 529425 but has different symptoms and, I > think, is more serious. I agree that this seems to be a different bug from bug #529425. It is worth noting that it seems this is the 2nd time in one year (see bug #435398) that a patch by Vitezslav Crhonek has broken crucial functionality of tcsh that my scripts depended on. Vitezslav, please stop changing the existing functionality of tcsh! Every time you do this you break existing tcsh scripts!
(In reply to comment #5) > (In reply to comment #0) > > Behaviour of expansion of multiple filename globs on a commandline > > has changed in the recent patch (tcsh-6.14-14.el5_4.2). Beforehand, > > a commandline expansion would fail with "No match" if all of the > > globs failed. Now if fails if _any_ glob fails. > > I am seeing the same problem. My sysadmin upgraded to > tcsh-6.14-14.el5_4.2 a few days ago and I just ran the new version for > the first time this morning. Immediately all my tcsh configuration > files started failing because they depended on the documented behavior > of tcsh that no-glob errors are only reported if all globs in the > command do not match. > > > This may be related to bug 529425 but has different symptoms and, I > > think, is more serious. > > I agree that this seems to be a different bug from bug #529425. > > It is worth noting that it seems this is the 2nd time in one year (see > bug #435398) that a patch by Vitezslav Crhonek has broken crucial > functionality of tcsh that my scripts depended on. Vitezslav, please > stop changing the existing functionality of tcsh! Every time you do > this you break existing tcsh scripts! The second patch you mentioned was written by Cai Xianchao and accepted by upstream in tcsh tcsh-6.16.00 (see http://mx.gw.com/pipermail/tcsh/2008-February/003923.html and upstream reaction in the same thread). Lately, it was dropped from upstream in tcsh-6.17.00 (see http://mx.gw.com/pipermail/tcsh/2009-April/003978.html and http://mx.gw.com/pipermail/tcsh/2009-May/003979.html) when you called attention on this. I'm really sorry for the latest problems, it wasn't my intention to break existing functionality. It'll be fixed.
*** Bug 538437 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0190.html
(In reply to comment #11) > An advisory has been issued which should help the problem > described in this bug report. This report is therefore being > closed with a resolution of ERRATA. For more information > on therefore solution and/or where to find the updated files, > please follow the link below. You may reopen this bug report > if the solution does not work for you. > > http://rhn.redhat.com/errata/RHBA-2010-0190.html The above link simply gives "Page Not Found (404) We're sorry! The page you are looking for has been moved or no longer exists."
The changes needed some time to propagate to all places. Now the URL mentioned above works correctly. Please, check out once again.