an", type "an" then hit Tab key would complete it to "anaconda". Then, if you additionally type "-" and hit Tab key, completed to anaconda-webui.log.." instead of "-", completed to anaconda.log.Filename completion is a feature of the shell, not the filesystem. If the shell supports it, it won't matter what filesystem, UFS. ZFS, ext2/3/4, FAT, etc.On ZFS (and if I recall correctly, {t}csh and some others excluding /bin/sh), incremental completions would work.
Define "substring completion". If you mean "filename completion" then I believe /bin/sh already does that. At least on my system with stock init files filename completion works with at least the ls command.Do you see a chance of substring completion getting implemented in /bin/sh ?
I would have to open an enhancement request?
Ok so standard completion is "starts with" not a regex.he wants fname completion with any substring like "rofi" shows .profile and such
you may hack libedit src/contrib/libedit.
That's a fuzzy search, textproc/fzf might be useful.he wants fname completion with any substring like "rofi" shows .profile and such
Yes, and if you can narrow a path name to a unique pattern that things like: "cd *cke*" can get you into a directory rather quickly. I only had one folder named docker that matched that, so it works out. However, if I had more than one match, it would give an error about not matching anything. Which is fairly sensible.That's a fuzzy search, textproc/fzf might be useful.
That's a fuzzy search, textproc/fzf might be useful.
I've reread both of these a few times and I'm having trouble seeing "usefulness".Yes, and if you can narrow a path name to a unique pattern that things like: "cd *cke*" can get you into a directory rather quickly. I only had one folder named docker that matched that, so it works out. However, if I had more than one match, it would give an error about not matching anything. Which is fairly sensible.
It's mostly useful for longer directory names, especially ones that came prenamed with annoying characters. There are a few limitations and the longer the list it has to sift through the longer it takes and more likely it is to give up. However, sometimes you have a very long directory name where just typing a couple letters and then using wildcards gets the whole thing in a couple keystrokes.I've reread both of these a few times and I'm having trouble seeing "usefulness".
The example of cd *cke* could return a list of directories that have cke in the name, then you use mouse to select the one you want and paste after a cd?
You get the same by "ls | grep -i cke", select with mouse, then type in cd and mouse paste.
Basically:
I think there are more than enough existing tools to accomplish the task so pulling in a fuzzy search/regex into the sh shell command is overkill/rediculous.
The old Unix philosophy of KISS, do one thing correctly using stdin, stdout seems to be forgotten.
My opinion only, and yes, I acknowledge 99% of people are going to disagree.
Ok, that sounds useful but only if a single match. Having multiple matches still seems to be a problem.It's mostly useful for longer directory names, especially ones that came prenamed with annoying characters. There are a few limitations and the longer the list it has to sift through the longer it takes and more likely it is to give up. However, sometimes you have a very long directory name where just typing a couple letters and then using wildcards gets the whole thing in a couple keystrokes.
And unlike the grep, it happens in one command rather than needing a second. Which is only an issue if you're about to do something destructive as it just does it without echoing back what it's about to do.
Fuzzy search is useful if you have a ton of files, spread out in different directories. That directory full of documents you've collected, and partially sorted but it's mostly a jumbled mess. You know you have it, but can only remember a partial filename. Now where did I put it? What the heck did I name it this time?Ok, that sounds useful but only if a single match.
Understood, but if the fuzzy search returns multiples we are back to the "pick one". Rereading this thread, it sounds like the OP desires "fuzzy search to return a single choice" which to me, "fuzzy" implies returning more than single choice which falls back to "how is that output different from ls | grep <pattern>"Fuzzy search is useful if you have a ton of files, spread out in different directories. That directory full of documents you've collected, and partially sorted but it's mostly a jumbled mess. You know you have it, but can only remember a partial filename. Now where did I put it? What the heck did I name it this time?
Oh, yes. But the nice thing about fzf(1) is, it gives you that list to pick from while you are typing the thing you are looking for. As you type that list gets shorter and shorter until you spot the thing you are looking for and can select it from that shortened list.Understood, but if the fuzzy search returns multiples we are back to the "pick one".
That I can fully agree with. Let the shell be the shell. /bin/sh is nice and small, let's not bloat it with a bunch of features that are easily added with an extra command or two. Besides, if you really want those snazzy features, install a different shell, there's a whole bunch of them to pick from. It's for your own user account, you are very much encouraged to install alternate shells. Just leave root's shell on /bin/sh (or /bin/csh).Yes I'll admit to being a Luddite/Old dog/just trying to understand and I can't grasp the "why" this feature should be wrapped into the standard built-in command
Ahh. That sounds useful for someone not me because my brain/fingers are wired for the way standard completion works (start of string, etc).Oh, yes. But the nice thing about fzf(1) is, it gives you that list to pick from while you are typing the thing you are looking for. As you type that list gets shorter and shorter until you spot the thing you are looking for and can select it from that shortened list.
It's a tool that works in a fairly specific situation, but when it works, it's rather useful. I wouldn't suggest using it all the time and in truth, I only use it from time to time. Most of the time, I prefer to just have more sensible names on my files and the like and not have to worry about it.Ok, that sounds useful but only if a single match. Having multiple matches still seems to be a problem.
Maybe it's just me. I use fname completion as currently defined in tcsh (so starting substring, not "substring anywhere") and would think completion of regex I'm expecting more than one.
So the "matching more than one" is the more likely case.
Again, I'm just trying to really understand the use case and if the match returns more than one, I don't see any usefulness beyond existing tools. Or "why may the existing sh builtin ls more complicated for a less than 1% use case".
Understood, but if the fuzzy search returns multiples we are back to the "pick one". Rereading this thread, it sounds like the OP desires "fuzzy search to return a single choice" which to me, "fuzzy" implies returning more than single choice which falls back to "how is that output different from ls | grep <pattern>"
I think that is an expand, not a complete.In the zsh you can type "cat *ui*" and hit TAB to make it complete to all matching names.