grep : Invalid back reference

[xuo]

Hi,

We have updated some of our CentOS 5.4 packages and it seems that grep does not behave as it was previously.
I could reproduce my problem on a simple testcase.

touch toto1
touch toto2
grep 'a b' toto*
grep 'a b1' toto*
grep: Invalid back reference.

A number (from 1 to 9) associated to the * in the file name definition seems to be a problem now for grep. How can I solve this problem ?

Regards.

Xuo.

[Rubberman]

From the grep man page:

      The backreference \n, where n is a single  digit,  matches  the  sub-
       string  previously  matched by the nth parenthesized subexpression of
       the regular expression.

Yes, I know you don't have any parenthesized sub-expressions. I've tried the same thing with files named test1 and test2 and get no such error. Also, I have a fully updated CentOS 5.4 system as well, and the date on /bin/grep is Sept 26. Make sure that you are running /bin/grep. There isn't one in /usr/bin, but it's possible that someone has created a link to another version, or installed another version somewhere in your execution path.

[xuo]

Hi,

Yes, I am using /bin/grep.

/bin/grep -V returns grep (GNU grep) 2.5.1
/bin/grep is not a symbolic link to anywhere (size is 88896 and date is Sep 26).

Regards.

Xuo.

[Rubberman]

Yep. Same as mine. Ok. I'm out of ideas here since I can't duplicate the problem. If you have a minimal example of the files that exhibit this and can post them here, I'd be happy to take a further look.

[xuo]

Hi,

Sorry for the delay for my response.
I do not have any file to give, as the problem appears even when the files are empty (touch toto1 for ex).
I asked to somebody else at work to do the same, and he had the same problem. This means that this problem does not come from my own environment.

Thank you for your help. I still try to find a solution.

Regards.

Xuo.

[xuo]

Hi,

I found something. My shell is tcsh. If I use bash, then there is no more any problem.

Regards.

Xuo.

[Rubberman]

Ok. It may be that tcsh is using a built-in version of grep. Try specifying the full path in your script.

[AstroAndy]

Just to add to the information, I have an identical problem in CentOS.

I have narrowed it down to:

* Any grep command from tcsh (with or without the full path to grep) where (a) there is a wildcard for the filename and (b) the search term contains a digit (i.e. 0-9).

I have also noticed other commands going odd recently when there are wildcards, so I suspect this is a significant part of the issue. For example, the command "rm .*~ *~" used to remove all emacs backups in the current directory., However, now it fails with "rm: No match." unless there are files that match both the wildcard components (i.e. a "hidden" file and a non-hidden file, not one or the other).

Does that help anyone?

Cheers
Andy

[Rubberman]

Shell languages have their own built-in commands, or have defined a number of aliases, with the same name as system commands. Their behaviour is usually similar to, but different from, the standard system commands. Both grep and ls are commonly redefined this way. Use which <cmd> to find out if it is a built-in or system command being run, and alias <cmd> to find out if the command has been aliased. For example, in my CentOS bash environment, this is the results of this:

# which ls
alias ls='ls --color=tty'
        /bin/ls
# which grep
/bin/grep
# alias ls
alias ls='ls --color=tty'
# alias grep
-bash: alias: grep: not found

So, you see that 'ls' has been redefined with an alias, but grep has not. When I run the above commands in the tcsh shell, this is the results:

# which ls
ls:      alised to ls --color=tty
# which grep
/bin/grep
# alias ls
ls --color=tty
# alias grep
#

[AstroAndy]

Yes I thought at first that that might be the problem myself, but I've:
(a) made sure all the commands I have problems with are "unaliased"
(b) used full pathnames to each one
(c) Checked everything with "which" and "alias"
(d) used "\ls", "\rm", "\grep" etc to force any aliases to be ignored.

None of it helps, unfortunately...