![]() In Unix/Linux grep cannot do anything about it because the tool starts after *.c is expanded by the shell. We saw that in Linux your command results in *.c being expanded first, recursiveness starting later. Your grep in Windows is from the GnuWin project, it is designed to reasonably mimic the GNU grep you can find in Linux. It's good to know what parts of your command (in general: any command) are (or may be) expanded by the (or a) shell.Īnd now, finally, the nuances of Windows. Note -include=*.c is still a pattern your shell may expand if you want your code to be robust then you should escape or quote the asterisk. You want the other way around and one method to do it is with -include=*.c (the other is with globstar where the shell handles the recursiveness, but it can give you argument list too long error so it's better to let grep do this). In short, the reason your code doesn't work is *.c is expanded first (before grep runs), recursiveness starts later (when grep runs). You would need to quote or escape the pattern to protect it from the shell (see this question). There are tools that actually interpret such patterns in some circumstances (in fact grep -include is an example).Įven if grep was designed to interpret this *.c in your code as a pattern in the way you expected, in many cases your code wouldn't work. If it sees *.c where it expects a pathname then it will try to read a file named *.c. This cannot help you because grep itself is not designed to expand patterns in an argument it interprets as pathname. If you escape or quote the asterisk in *.c (examples: \*.c, "*.c", '*'.c) then it will not be expanded and the word will be passed to grep literally as *.c. ![]() If there is no match in the current working directory then ( in some shells) *.c will not be expanded and it will be passed to grep literally as *.c.There are two scenarios where grep actually sees this *.c: The job of picking all pathnames matching the pattern would be done by the shell. dir1/subdir/baz.c), grep would not see the pattern itself, -r might be irrelevant. If you properly used such pattern, the shell would pass all matching paths to grep (e.g. This feature is called "globstar" and one may need to explicitly enable it in a shell. In some shells you can use a glob that can match files in subdirectories. foo.c is a file of the type directory then -r will make grep descend into the directory but grep will read all files in the directory (it is still not aware of *.c you typed). If foo.c and bar.c are regular files then -r is irrelevant.It sees -r, iflag, bar.c, foo.c as its arguments. The above grep is not aware *.c was used.if there are two matching files foo.c and bar.c then your command will effectively be: grep -r iflag bar.c foo.c *.c is expanded to possibly multiple arguments: names of matching files in the current working directory. The first important thing that happens in Linux is the shell tries to expand *.c before it starts grep. it does not give you what you expected either. So let's assume for a while you run the command in Linux. You mentioned GnuWin, your OS is Windows, you probably used grep inside cmd.exe this brings some interesting nuances (we will get to them), but still your grep is designed to mimic GNU grep in Unix/Linux. To understand what happens, it's good to analyze first how this command behaves in Linux. Why your code does not work like you expectedĪnd you expected grep to recursively (because of -r) examine the current working directory and consider only files matching the pattern *.c. No answer posted so far has explained why your original code does not work like you expected. For what you want to do, using -include is the right way credit goes to other answers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |