![]() ![]() ![]() ![]() In this case, I'd have myprog go ahead and use X.Ģ. Neither X nor Y contains any myprog wildcards. If it does come from wildcard expansion and the source was Y, then there are a few cases.ġ. If the shell tells it that X did not come from shell wildcard expansion, myprog can safely use it. Suppose myprog is invoked and it sees it has one argument, X. Let's say myprog takes one argument, which it expects to either be a file name or a wildcard in some pattern language that is not necessarily the same pattern language used by the shell. E.g., if the argument was a?c which expanded to abc, the shell would tell the program it was a?c, not merely ?. When I said "For those from wildcard expansion, it would tell the program what the wildcard was" I meant the shell tells the program the full argument containing the wildcard, not just the wildcard part. Why should all programs tie themselves to the mechanisms of any one particular shell?įirst, a clarification. > Different shells have different globbing mechanisms. The original developers of the shell language were most certainly not stupid. what? Where did those quotes come from? More importantly, how do you propose to remove them? My point is, the current behaviour is simple and consistent as well as powerful and flexible, and I suspect people are just going "it doesn't work the way I thought it would" and downvoting my comment when they really haven't thought about the perfectly logical explanation for why things are the way they are. This is very consistent observe that if $SOMETHING contains "foo bar" (without the quotes), thenīut what you seem to be suggesting is that it becone The fact that the variable substitution could expand to multiple arguments (because it's really just simple textual substitution) is in fact very powerful and useful (you can pass multiple arguments in one variable, for example), and you can always quote if you really want it to expand to one argument, the same way you would quote strings containing spaces to make them one argument. I mentioned that already, it's a basic part of the understanding and is not surprising at all.Īgain something most people arent going to want. It going to fail if the variable has any spaces You completely ignored my point, which is that none of this behaviour should be surprising or unexpected to anyone who has taken the time to think about how it all works together, and that this flexibility is the inherent way in which the UNIX command line is so powerful. But I didn't go out of my way to be incompatible with grep either. Please note that ripgrep is not and is not intended to be a drop-in replacement. So you'll find a lot of overlap there too. Ripgrep also tries to use the same names for flags as grep, wherever possible. If you really do not want any kind of smart filtering, then yes, you'll want `alias grep="rg -uuu"`. In a large number of cases, if you `alias grep=rg`, then most things will continue to work as you expect. > Do either of these tools have a "grep" mode, so that I can alias grep to it and get similar, but improved, behavior?Īnother commenter already mentioned `rg -uuu`, and that's pretty much the right answer. Yes, that's what I did for about ten years before I wrote ripgrep. As is I just have a grep wrapping shell script to give it some sane defaults which works fairly well. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |