The man page for grep reads
-i,--ignore-case
Ignore case distinctions in both the PATTERN and the input files. (
-iis specified by POSIX.)
However, if I change case on a filename, it won't work.
$ touch WHATEVER
$ grep -i pattern whatever
grep: whatever: No such file or directory
Am I missing something?
That confusing snippet was changed in newer versions of GNU grep to:
-i,-ignore-caseIgnore case distinctions, so that characters that differ only in case match each other.
See this commit: http://git.savannah.gnu.org/cgit/grep.git/commit/?id=e1ca01be48cb64e5eaa6b5b29910e7eea1719f91
.BR \-i ", " \-\^\-ignore\-case
-Ignore case distinctions in both the
-.I PATTERN
-and the input files.
+Ignore case distinctions, so that characters that differ only in case
+match each other.
As to where the old formulation may originate, some programs like less(1) have a (mis)feature[1] where using an uppercase letter in a pattern will turn off case insensitivity for a particular search (override the -i flag). The author of that doc snippet probably assumed that many people expected that behavior, and instead of some direct caveat, preferred that non-committal sentence. FWIW, such a feature was never a part of ed(1), grep(1), vi(1), perl(1) etc. or of the regex(3) or pcre(3) APIs.
[1] that seems to have its origins in emacs, where it's the default; there you can turn it off by setting the (customizable) search-upper-case variable to nil.
less behaviour very useful. I would never use uppercase characters in my search query if I intended the search to be case sensitive. It's a sensible default IMO
less -i for "hello" but not "Hello"? As to the interaction between case insensitive search, compatibility chars like fi and locales, there are many nasty problems (while there, don't forget the titlecasing (eg Lj, lj , LJ = U+01C7-U+01C9), another horrible contraption for a non-existing problem).
less by entering -i and -I within less. The default is case-sensitive, -i is the default chosen by mandb, git, and IMO is useful. For a complete case insensitive (like for your copy-paste case), there's -I. vim has the smartcase option as an equivalent of less -i behaviour. GNU info and GNU emacs behave like less -i in this instance.
Apparently I have a different manpage.
-i, --ignore-case
Ignore case distinctions, so that characters that differ only in
case match each other.
In any case, it's not about the filenames.
It ignores case in the file (contents) but also in the pattern.
Test file:
___________
Hello World
^^^^^^^^^^^
Grep results (ignore case of file contents):
$ grep hello test.txt
$ grep Hello test.txt
Hello World
$ grep -i HELLO test.txt
Hello World
$ grep -i hello test.txt
Hello World
Grep results (ignore case of pattern):
$ grep [a-Z] test.txt
grep: Invalid range end
$ grep -i [a-Z] test.txt
Hello World
$ grep -i [A-z] test.txt
Hello World
$ grep [A-z] test.txt
___________
Hello World
^^^^^^^^^^^
As you can see the results can sometimes be a little unexpected.
Not sure if there is an example where this actually matters more.
less, for example, there's a -i mode in which matching is case-insensitive if you only use lowercase letters in the pattern, but if there are any uppercase letters in the pattern, the whole thing is case-sensitive. That's like (sometimes) ignoring case in the contents but not the pattern.
"It ignores case in the file (contents) but also in the pattern", this suggests (although it doesn't necessarily say it), that it is possible to ignore case in the pattern, but not in the contents. I'd like to understand how this would work (ignoring pattern, but not contents -- or the other way around).
Well, for example, it could be written so that a pattern of “hello” would match “Hello” in the file, but not vice versa. While this sounds hypothetical, it is the way spell-check works. If your dictionary contains “stack” and “exchange”, and your document contains “Stack Exchange”, spell-check will succeed without error. But if your dictionary contains “Unix” and your document contains “unix”, that will be flagged as an error.
Using the -i flag ignores the case of the matches, not the case of the filenames. You created a file whose name is all uppercase, but you told grep to open a file whose name is lowercase, leading to the "file not found" error message. Linux filenames are case-sensitive.
"in both the PATTERN and the input files" = "in the pattern and in the input files". The preposition "in" applies to both clauses joined by "both".
If the authors had intended to ignore case distinctions in both the PATTERN and the input filenames, they would have said so.
In comments, OP explains that the Question is incorrectly framed. In response to OP's actual difficulty: The first line of the description on the man page you cite is "grep searches the named input FILEs (...) for lines containing a match to the given PATTERN." That is, grep searches for matches to the contents of files not for matches to their names.
Of course, OP's clarification makes the accepted answer nonresponsive to the hidden question.
whatever is the string "whatever"?
whatever, which the accepted answer does not in any way address. I am not aware of any version of grep that will look inWHATEVERwhen you ask it to look inwhatever, under any circumstances. The accepted answer addressesgrep -i PATTERN whatever, which is notgrep -i pattern WHATEVER. Case-sensitivity of filenames is a *nix thing, not agrepthing.