Filename completion with forward slashes

Apr 7, 2010
37
0
I use mingw and several unix-based utilities, many of which expect paths to use forward slashes. However, for filename completion, TCMD does not seem to accept strings with forward slashes.

REQUEST: It would be great if TCMD had an option or a hotkey that would allow filename completion on strings that contain either forward or back slashes.

If a way already exists, please let me know. Thanks.
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,769
47
Albuquerque, NM
prospero.unm.edu
I use mingw and several unix-based utilities, many of which expect paths to use forward slashes. However, for filename completion, TCMD does not seem to accept strings with forward slashes.

REQUEST: It would be great if TCMD had an option or a hotkey that would allow filename completion on strings that contain either forward or back slashes.

If a way already exists, please let me know. Thanks.
It works fine for me, with UnixPaths=Yes.

In fact, with UnixPaths and AppendToDir both set, not only does TCC accept forward slashes, but tab completion actually inserts forward slashes instead of backslashes when completing directory names.
 
Apr 7, 2010
37
0
Thank you. I checked under "Filename Completion" in the help file and did not see any option. Now that you told me what to look for, it seems obvious. I should have known it would already be covered. I just wished I had asked much sooner. Thanks for a great product.
 
Dec 7, 2009
221
2
Left Coast, USA
The directory-name completion routine is smart about this. I have a SupportFiles subdirectory of C:\TakeCommand. If I go to C:\TakeCommand and type "dir suppo", then press Tab, this appears: "dir SupportFiles\".

But if I type "dir ./suppo" and press Tab, I get: "dir ./SupportFiles/". Nice touch, that.

I'm very glad not to be plagued by case-sensitivity in these situations. For some bizarre reason known only to some dev who's probably still locked up in chains somewhere in the basement parking-lot of Building 42, cmd.exe couldn't care less about matching case except when it comes time to do filename or directory name completion with the Tab key. Get the capitalization wrong, and <beep>. Makes no sense at all.
 
Dec 7, 2009
221
2
Left Coast, USA
I was thinking of a building 42 at a tiny software company somewhere north of Oregon and west of Idaho. But it could have been a different building #. :--)
 
May 20, 2008
3,520
3
Elkridge, MD, USA
Possibly associated with the name adoption I suggested in another thread recently? But the OP is oriented toward Unix and its derivatives, which originated in New Jersey, and are epitomes of intentional case sensitivity.
 
Dec 7, 2009
221
2
Left Coast, USA
Re: intentional case sensitivity: understood. I'm referring in a somewhat snide vein to some unintentional and unnecessary case-sensitivity that was never fixed. Or else it was entirely intentional, and therefore completely irrational.
 
Last edited:
May 20, 2008
9,153
58
Syracuse, NY, USA
cmd.exe couldn't care less about matching case except when it comes time to do filename or directory name completion with the Tab key. Get the capitalization wrong, and <beep>. Makes no sense at all.
What are you referring to here, mikea? I find no problem with CMD's tab completion.
 
Dec 7, 2009
221
2
Left Coast, USA
> what are you referring to here

To my chagrin I just realized I've been mis-speaking (argh) -- mixing up one cmd.exe problem with another. It isn't the filename completion feature that's case-sensitive. It's the retrieval of history items. If I type "dir" and then "Dir /w" (capital "D" in the second case)...later, if I type "d" alone and press F8, the only command cmd.exe retrieves is "dir" -- it can't find "Dir /w" in its command history. If instead I type "D" alone and press F8, cmd.exe retrieves the "Dir /w" command but not "dir" (without the switch). 4NT/TCC have never had this limitation. I suppose there must be some tiny registry hack to overcome it, but expending much effort to improve the behavior of cmd.exe is mostly an exercise in futility.