wildcards not expanded.

[ghost]

From skippy.hammond@gmail.com on July 04, 2012 08:13:01

What steps will reproduce the problem? 1. Go to a directory with some, eg, .txt files.

2. Enter "dir *.txt" and press tab. What is the expected output? What do you see instead? Expected: If there is exactly 1 .txt file the tab should complete that name. If there are more than 1, then a second tab should list all .txt files.

Actual: nothing is expanded.

Original issue: http://code.google.com/p/clink/issues/detail?id=31

[ghost]

From martin.r...@gmail.com on July 06, 2012 08:40:10

I've yet to think of a way to solve this, as it is now Readline that controls command line input and it doesn't have support for wildcard matches (you can't do it in Bash). I decided it was a little-used feature of cmd.exe so let it slide.

Wildcard completion is well suited to cmd.exe which cycles through it's matches. Readline's incremental approach doesn't lend itself well to wildcards, as it's expecting what you've already typed to be part of the final result.

By way of an illustration, consider this (where is a keypress and _ is the cursor);

c:>type .txt 1.txt 2.txt 3.txt 4.txt c:>type .txt_

What does one type next to select one of the matches? Alternatively, if we were to have a custom completer change it to 1.txt, next time we press , Readline is going to match 1.txt and thing we're done.

[ghost]

From skippy.hammond@gmail.com on July 06, 2012 18:09:27

The msys bash seems to support it - I have a dir with README.txt (the only .txt file) and entering "cat *.txt" expands it out. If there are multiple, it behaves exactly like you describe (ie, the second TAB moves the cursor to the end of the wildcard.

I found a little on readline's capability at https://bbs.archlinux.org/viewtopic.php?pid=1005272 that said though, I agree it isn't particularly useful when multiple matches exist, and I think if you go down the path of trying to "enhance" readline to be more like cmd's native completion it is s slippery slope that might result in the worst of all worlds. So I'd be inclined to treat this as a low priority, and if it turns out to be truly problematic, to just reject it!

[ghost]

From william....@gmail.com on November 13, 2012 04:26:22

It works in Bash on my mac, version: 3.2.48

With the following in my .inputrc Bash works just like cmd.exe TAB: menu-complete

[ghost]

From michael....@gmail.com on October 03, 2013 12:12:09

This cmd's issue can be very useful - it happens to me a lot that I have to run one of the ~2000 scripts in a directory, while there are a lot of similar (rather long) names differing by some number at the end (yes, that's ugly). So in the usual cmd, to run a_long_named_ugly_script_123 I would type something like

run_script *123 and that would expand automatically given 123 is unique. With clink I have to type all the long name beginning....

[aaron-meyers]

I just wanted to raise this one again. I've started using clink recently within ConEmu and this is really the one thing that is constantly biting me (otherwise loving it!). The pattern that Michael mentioned in the last post is very common in my environment -- mostly with unique file extensions. For example, I was accustomed to going to a folder and using "notepad *oj TAB" to open a Visual Studio project file in the folder. I'll probably end up writing a script or two to work around this in the most common cases but would still love to see this functionality implemented in clink.

[chrisant996]

This is one of the next things I'll implement in the chrisant996/clink fork. It's currently the only thing left that's keeping me from being able to use an alpha build of clink as my daily driver.

[chrisant996]

Implemented in chrisant996/clink fork.