Here is the command and its output:

# echo 401 | grep [0-9]
401



Normal, right? Now look what happens when I change the number:

# echo 420 | grep [0-9]
#

What's up with that????

Same for any line that ends in 0:
# echo 4400 | grep [0-9]
# echo 440223453243430 | grep [0-9]
# echo 990223453 243430 | grep [0-9]

Put something else as the final character:
# echo 440223453 243430t | grep [0-9]
440223453 243430t

And grep lets it through. I have several systems, this is the only one on which I've seen this behaviour.

# grep -V
GNU grep 2.6.3

# cat /etc/redhat-release
CentOS Linux release 6.0 (Final)

Update:
Now I'm not sure what the failure pattern is. When I run:
echo 440x | grep [0-9]

it returns nothing also. This can't be a bug, it's too huge. I must be missing something.

Log out, log back in, works normally now.

I went back through every command I ran in the session where it was screwed up. I can't see anything that would have any bearing on how grep, echo, or bash in general operates.

No clue. But it's working now. For now.

A friend of mine says, "your shell is interpreting the [] characters before sending them to grep,
quote your regex strings."

Unfortunately I can't test to see if he's right, since it's working now and I have no idea how to reproduce the problem.

The only thing worse than not knowing the reason for a problem is not knowing how it got fixed.......

I don't understand why you can't test what you've learned---take your original example and repeat using quotes.

in such cases you should almost never think grep is broken (or sed or whatever). If grep was broken so clearly it would be fixed already. No, that is not a bug in the software, but misunderstanding of the environment. Believe me, grep (sed/awk/...) works exactly as planned and implemented. So you need to find out what can cause this behavior.
An easy trick to execute echo grep [0-9] (or simply echo [0-9]) and you will see it is evaluated. To keep it as is you need to avoid evaluation, you need to look for quotations (as it was already mentioned).





_____________________________________
If someone helps you, or you approve of what's posted, click the "Add to Reputation" button, on the left of the post.
Happy with solution ... mark as SOLVED
(located in the "thread tools")

I know - dumb thought. It was just so weird.


I can't test the solution if I can't reproduce the problem. Trying the solution in an environment that isn't messed up doesn't yield any useful results:

# echo 420 | grep [0-9]
420
# echo 420 | grep "[0-9]"
420

# echo grep [0-9]
grep [0-9]
# echo grep "[0-9]"
grep [0-9]

The results will depend on whether any files with names that are just a single digit exist in the current directory. Try your "echo" test when there is a file named "3" (without the quotes) in the current directory. Try it again when there are files named "3", "4", and "5", and consider what grep would do in that case.

1 members found this post helpful.

Too cool. So the shell IS interpreting the regex before it gets to grep.

# echo 420 | grep [0-9]
420
# touch 0; echo 420 | grep [0-9]
420
# mv 0 1; echo 420 | grep [0-9]
# mv 1 2; echo 420 | grep [0-9]
420
# mv 2 3; echo 420 | grep [0-9]
# mv 3 4; echo 420 | grep [0-9]
420
# mv 4 5; echo 420 | grep [0-9]
# mv 5 6; echo 420 | grep [0-9]
# mv 6 7; echo 420 | grep [0-9]
# mv 7 8; echo 420 | grep [0-9]
# mv 8 9; echo 420 | grep [0-9]
# rm -f 9; echo 420 | grep [0-9]
420


And, if I use quotes (grep "[0-9]") it works in all cases. Very cool. I like learning new linux stuff.

On the topic of grep behaving strangely, beware of invisible characters like the Windows style newline characters.