Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Filename completion with forward slashes

Apr
42
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.
 
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.
 
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.
 
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.
 
Is bldg 42 in Northern NJ (where Bell Labs, now deceased, used to be)? That's where the only case-sensitive software that ever became widely used came from...
 
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 #. :--)
 
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.
 
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:
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.
 
> 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.
 

Similar threads

Back
Top