-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add --iglob flag #163
Comments
Should |
Do other tools that do globbing also match case insensitively? |
Should we really be spending resources trying to match extensions like If there are common case-insensitive equivalents of certain extensions, then maybe they should just be explicitly added. |
On windows, definitely. |
ack supports the selection (case sensitive or not) for globing:
And the reason, why it is not done in one step: https://beyondgrep.com/ack-2.0/ . |
I would like to see precedent established by other tools before moving On Oct 11, 2016 5:07 AM, "hefengrren" [email protected] wrote:
|
For example, what do grep, find and git do? On Oct 11, 2016 6:14 AM, "Andrew Gallant" [email protected] wrote:
|
Windows is not special, OSX has the same "issue" for compatibility: https://www.quora.com/Why-does-OS-X-choose-to-have-a-case-insensitive-file-system-instead-of-a-case-sensitive-one . Git has a config |
Folks, I am neither a Windows nor a Mac user. I don't have a whole lot of knowledge of how those platforms work. Please help me understand the problems and what other tools do. Git's Note that enabling case insensitive globbing could result in a very large performance hit. |
Sorry for the terse reply earlier - it was just a gut reaction as a Windows user. The general rule on Windows is that all file operations are case insensitive, alas... I've since tested git on Windows (with core.ignoreCase on), and .gitignore files are case insensitive there. I do think supporting this is important, even with a performance hit, as my fellow teammates add rules expecting that Otherwise, find.exe from the git for windows distribution behaves as on Linux, unless you change the flag:
Well, almost:
In the short-term, it's not a huge deal for me - there are only a couple of rules that need duplicating in my current .gitignore files. |
I suspect you're right that some kind of support for case insensitive matching is a good thing. |
I think there's still some question on how we want to expose it. e.g., Reading |
I'd rather have support directly in file types: |
Mac is effectively case insensitive. Most functions ignore case, and you can't have two filenames which differ only by case. Here's an example to give you the flavour. This means mac users usually don't care about case. Windows obeys the same kind of rules (you can't have
|
@ChrisJefferson Right, but what do tools that provide some sort of globbing do? If you type |
On windows, |
The Mac filesystem is case-insensitive, but most CLI tools that search filenames/directory contents (as opposed to passing the string through to the filesystem to e.g. open or chdir) are still case-sensitive by default. |
That said, I do agree that filetype detection should always be case-insensitive, regardless of how globbing works. |
Interestingly, on Mac, As written in my linked duplicate issue, I believe that if at all feasible, Otherwise, I believe As for types, I'm not sure. On one hand I think symmetry is valuable and |
How does one detect whether a file system is case sensitive or not? Does
this check need to be done for every file path?
…On Jan 19, 2017 23:11, "Thijs van Dien" ***@***.***> wrote:
Interestingly, on Mac, ls and find are both case-sensitive by default. On
Windows (through Gow <https://github.com/bmatzelle/gow>), find is still
case-sensitive but ls isn't.
As written in my linked duplicate issue, I believe that if at all
feasible, rg should adhere to the rules of the filesystem that any
particular file is on—a search may span multiple volumes, some of which
case-sensitive and some of which not!—with potentially the option to force
case-sensitivity everywhere.
Otherwise, I believe iglob is a good option, since I like the idea of
mixing and matching with glob; for example rg --iglob '*.txt' --glob
'!*.txt' --files to find all text files that do not have an all lowercase
extension, though I'm not sure rg would or should be an ideal tool for
that.
As for types, I'm not sure. On one hand I think symmetry is valuable and
--itype(-not) would allow for a similar use case as above, where
--type(-not) refers to canonical forms and --itype(-not) would match
non-canonical forms too. That makes it a per-type issue, though. It might
be easy to agree on that *.RS is bad naming, but *.TXT or *.SQL not so
much...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#163 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAb34vmyamudLhJ1AZuTM_dMsYBgJ6zhks5rUDQKgaJpZM4KTKwE>
.
|
I'm afraid so, if you don't want to run into edge cases (like possibly for symlinks). Otherwise at least per directory, because one can mount one volume within another. On Windows it would probably be |
@thijsvandien You're wrong (about Mac, I don't know about Windows). Any path you pass as an argument to both As for ripgrep, I think that filetype detection should be case-insensitive by default, regardless of filesystem, because file extensions are generally considered to be case-insensitive (e.g. |
I did mean the |
|
Why? Others in this thread have shown that globbing itself is case insensitive on certain file systems. There are clearly performance trade offs involved in this choice, which makes it even harder to choose the right path. Both "check every file path" and "globing/types are case insensitive" have the potential to regress performance, so I think some experiments need to be done before we can move forward. Performance alone might not be enough to completely rule out whether we add case insensitivity to ripgrep, but it could certainly impact whether it's the default. |
On unices, globbing is case-sensitive by default. Yes, Bash (and presumably other shells) has an option to make globbing case-insensitive, but you have to opt in to that behavior. I don't really care how it behaves on Windows, so I wouldn't have any issue if you did case-insensitive globbing there, although I would expect that it's more valuable to have consistent behavior. Regarding Rakefile, since that's not an extension, I think it's reasonable to do a case-sensitive match against Rakefile and RAKEFILE (so e.g. RaKeFiLe doesn't match), although you may want to find out how |
I think that, at the very least, we should be able to add a
|
Working with Chris Stadler, implemented BurntSushi#163 (comment)
I started looking into implementing |
Working with Chris Stadler, implemented #163 (comment)
@PeterSP It does certainly feel like we should respect |
This was done in #531 |
Take HTML for example:
ack --html
matches *.html, *.HTML, *.Html ...But,
rg -thtml
only matches *.html.The text was updated successfully, but these errors were encountered: