Total Commander

2ghisler(Author)
What exactly are you referring to? And what about the other issue?

You can't support both files with dots at the end and those without when using an ambiguous name like "*." or similar.

2ghisler(Author)
You added a dot at the end. Therefore you need to support files without dots. See the title.
*. is just a search mask, and the file name is passed through %1. They're different things.

ghisler(Author) wrote: ↑2022-11-08, 16:32 UTC You can't support both files with dots at the end and those without when using an ambiguous name like "*." or similar.

Supporting both methods at the same time is indeed problematic. But both methods are not needed at the same time. Either a program works one way or the other way, but not both ways at the same time. The problem is that sometimes TC uses one method and sometimes the other, while the user has no control over which method is used. That's why I suggested to give the user control over which method is used in each separate case.

You still haven't responded to the bug that a program gets associated with the wrong files while the icons show the correct associations. This because you use the wrong internal representation of a filename (with a dot added to the filename). The property tc.fullname of a file should never include a dot that isn't there and the regular expression \. should never match with a filename if there is no dot in the filename.

I think it's probably best to remove the last dot at the end of a file name when receiving a name via /S=L switch. This way Lister can still open these when you view them internally with F3, but not with Enter. Such names are normally forbidden, so it's probably a better solution than how it is now, but not a perfect solution either. I don't want to remove the trailing dot when opening files via internal or external associations, this change may break a lot of other things...

ghisler(Author) wrote: ↑2023-02-13, 09:49 UTCthis change may break a lot of other things...

A lot? List a few, please.

ghisler(Author) wrote: ↑2023-02-13, 09:49 UTC I think it's probably best to remove the last dot at the end of a file name when receiving a name via /S=L switch.

Seems reasonable.

ghisler(Author) wrote: ↑2023-02-13, 09:49 UTC .., so it's probably a better solution than how it is now, but not a perfect solution either.

I think the best solution, like I said before, is to also give the user control of whether or not the dot at the end is removed by Lister and whether or not the dot is added by TC.

As I said, for Lister this could be achieved by adding an option to /S=L:options, for example D or D1 to keep the dot (assuming you remove it by default like you suggested). That way Lister can also be used in combination with programs that do not add a dot at the end and do support filenames that end with a dot. Or in combination with TC via a button, etc. and in combination with TC's association if TC could be instructed not to add the dot.

I don't know if it's doable, but to control whether or not TC adds a dot at the end, I suggested implementing a modifier in the various command fields. That way TC could work together with programs that expect a dot at the end and programs that cannot handle the dot at the end. And regardless of whether an association is used for that, or a button on the button bar.

white wrote: ↑2022-11-09, 12:52 UTC You still haven't responded to the bug that a program gets associated with the wrong files while the icons show the correct associations. This because you use the wrong internal representation of a filename (with a dot added to the filename). The property tc.fullname of a file should never include a dot that isn't there and the regular expression \. should never match with a filename if there is no dot in the filename.

You still haven't responded to this separate issue.

This should be fixed in TC 11 beta, please test it.
Fixed: Lister: When started via command line, e.g. %commander_exe% /S=L "%1", ignore a trailing dot in passed file names

It works! It's necessary to check for Win 10/11.

It's necessary to check for Win 10/11.

Why? The problem can also occur on older versions.

I understand. Just above was called the problem of old versions of Windows with notepad and Far, where the behavior is different.