WAD tab-completion bug with zip

[ClioCJS]

For some reason — I assume a bug — pressing <TAB> to fill in a filename does not work after the 'zip' command, even though it seems to work after all other commands (including non-existent commands).

As a test case, I actually have identical aliases — zip and zipp — and the behavior of <TAB> after typing the command behaves differently!

I realize a factor in this situation is 'zip' being a reserved command—but so is copy, and copy isn't behaving that way! None of the other ones are.

It works right for zipp + everything else.
It works wrong for zip — even if it's been aliased to something else.

The screenshot below is what happens when i hit <TAB> after a command/alias such as copy, du, zip, or zipp

It's the one time tab completion fails for me in TCC, and it's been consistent over multiple versions. I basically had to make my zipp alias to get around this.

Side-note: This bug does not manifest if I use *zip, but again, this is still inconsistent with all other commands (including unknown).

 

[Charles Dye]

The default filename completion for ZIP is to include .ZIP files and directories for the first argument. If that's not what you are seeing, the values of any FileCompletion environment variable or .INI directive would be relevant.

 

[ClioCJS]

That probably the problem then --

The zip command is used to create zip files, so it doesn't make sense for it's filename completion to complete to a zip file, as the file you are zipping by definition will not be a zip unless you're zipping a zip inside of a zip.

So I'm in a situation of trying to zip a folder (or a file), and it won't complete to the folder name I want to zip. It doesn't makes sense to complete to .zip when creating a zip. The create-zip name is going to be user-determined and not something tab-completed to.

 

[ClioCJS]

I don't use any FileCompletion customization. That's cool that that functionality is available though!

Is there a quick fix where i can make zip autocomplete the way everything else does? Because at almost no point am i ever using the zip command on a zip file (unless i'm going russian doll with zip files). I always use zip to create, unzip to view.

 

[Charles Dye]

For starters, you can

set filecompletion=zip:*;

If that does what you want, then you can use the OPTION dialog to make it more permanent:

Is there a quick fix where i can make zip autocomplete the way everything else does? Because at almost no point am i ever using the zip command on a zip file (unless i'm going russian doll with zip files). I always use zip to create, unzip to view.

But.... When you use the ZIP command to create a .ZIP file, the first argument is the name of the .ZIP file you are creating, right...?

 

[ClioCJS]

Thanks, that did the fix I wanted!

To answer your question of "But.... When you use the ZIP command to create a .ZIP file, the first argument is then name of the .ZIP file you are creating, right...?"

The answer is yes, but the gotcha is: Yes, but that file doesn't exist (because we haven't created it yet), so we can't tab-complete to it.

Basically, with the zip command, unless you're doing update/refresh, there is 0% chance tab will ever complete to the file we are zipping. And a 100% chance that the person is wanting to zip a file or folder -- but for some reason we've chosen to only autocomplete to folders (which seems to acknowledge this reality) and not to files (which seems to deny this reality).

I'm glad the fix is quick though!

 

[rconn]

Thanks, that did the fix I wanted!

To answer your question of "But.... When you use the ZIP command to create a .ZIP file, the first argument is then name of the .ZIP file you are creating, right...?"

The answer is yes, but the gotcha is: Yes, but that file doesn't exist (because we haven't created it yet), so we can't tab-complete to it.

This is WAD.

Not sure why you would be trying to tab-complete a file that is not a ZIP file, or which doesn't exist, as the first argument to ZIP. The first case would cause ZIP to fail, and the second case would fail a tab completion because there's nothing to complete.

 

[ClioCJS]

This is WAD.

Not sure why you would be trying to tab-complete a file that is not a ZIP file, or which doesn't exist, as the first argument to ZIP. The first case would cause ZIP to fail, and the second case would fail a tab completion because there's nothing to complete.

*zip newzip.zip long_filename_i_dont_want_to_type is the use case here.



You tab complete the file you want to zip that you don't want to type the long name for.

In my case i have a zip.bat that takes a filename as %1 and auto-generates the zip name. So the first argument is not a zip file.

But I fixed it with the custom autocomplete behavior command I dodn't know about. Good stuff.



It's the only time in my 30 yrs of using TCC that I've ran a bat file and not been able to use tab to cycle through the file i want to be the first argument to that bat file. And it's because zip was reserved. B

But still. The only things you would ever zip are files and folders. Of course you'd want to use tab-completion rather than typing them out. It doesn't make sense to suppress this.


Prior to the fix, I ended up in the awkward situation of having to tab-complete to the file i wanted to zip, then inserting "zip" before the filename, until the custom autocomplete fix.

 

[rconn]

The problem here isn't the ZIP file completion, it's that you're using a batch file to override an internal command without disabling the internal command.

As the online help says:

--------------------------------

For example, the default ZIP filename completion looks like this:

zip:[1] dirs zip [2*] *

This means that the first argument to a ZIP command will only match subdirectories or files with a .zip extension. Subsequent arguments will match any file or directory.

-------------------------------

So you can match any filename, just not as the first argument to ZIP (where anything other than a directory or a *.ZIP file would case ZIP to fail).

 

[Charles Dye]

As the online help says:

--------------------------------

For example, the default ZIP filename completion looks like this:

zip:[1] dirs zip [2*] *

This means that the first argument to a ZIP command will only match subdirectories or files with a .zip extension. Subsequent arguments will match any file or directory.

-------------------------------

I've been wondering, but never got around to asking. Or testing. When tab completion parses args, are they all counted the same? Or do arguments beginning with a forward slash -- options -- get counted differently?

It seems to me that "first argument", "second argument", and so on ought to refer to the first, second, etc. non-option argument -- the first, second, etc. argument not beginning with a slash. But maybe it already works that way. And if not, it might not be worth the bother to add. Haven't really thought it through.

 

[rconn]

I've been wondering, but never got around to asking. Or testing. When tab completion parses args, are they all counted the same? Or do arguments beginning with a forward slash -- options -- get counted differently?

Presto, already done. It's always worked that way.

 

[Charles Dye]

Presto, already done. It's always worked that way.

Way ahead of me as usual.

 

[vefatica]

It's a very likely scenario for me to give a zip file the same base name as a file I'm putting into it. If, for example, I want to create creationdate_to_filetime.zip and put the existing file creationdate_to_filetime.btm in it, I have to type the whole name of the zip file. It's much easier to complete the name and then change the extension. If the name would be completed after 4 keystrokes (perhaps c,r,e,tab) that's 10 keystrokes vs. 28).

ZIP is one of the reasons I defeat the default completion as much as I can.

 

[rconn]

The ZIP tab completion has worked this way since v22. If it's taken this long for anyone to fuss about it, it's (1) obviously not particularly important, and (2) not going to change and break it for everyone who hasn't complained.