Internal associations: error searching for a file without a dot in the name

[Fla$her]

Type name: *.
Open: "%COMMANDER_EXE%" /O0 /S=L "%1"

Code: Select all

---------------------------
File not found!
---------------------------
C:\test.
---------------------------
ОК   
---------------------------

"%COMMANDER_EXE%" /O0 /S=L "C:\test" works from command line.

Open: notepad "%1"
There is no mistake. The file opens in notepad.

And in the following case, the system window "Open with" opens:

Code: Select all

[Associations]
Filter1=>NoDot
Filter1_open=""%COMMANDER_EXE%" /O0 /S=L "%1""

[Searches]
NoDot_SearchFor=^[^.]+$
NoDot_SearchFlags=0|002002001020||||||||22220|0000|||

[white]

"%COMMANDER_EXE%" /O0 /S=L "C:\test" works from command line.

But "%COMMANDER_EXE%" /O0 /S=L "C:\test." does not work.

Lister cannot handle a trailing dot. Try for example on TC's command line:

Code: Select all

cm_List "c:\test."

[Fla$her]

2white
The mask *. looks for names without dots, so there is no point in your example. %1 passes the path of the file under the cursor, it has nothing to do with this dot, it simply cannot be at the end of the names.

[white]

2Fla$her

Yes, TC adds a dot at the end because otherwise notepad.exe will try to open filename.txt instead of filename when I just pass c:\path\filename to it.
You cannot create files with a dot at the end with normal Windows function calls, you have to use a very specific syntax to bypass the file system checks, which Far must be doing. I'm sorry but i don't think that there is a solution which works with both Far and Notepad.

[Fla$her]

Maybe it was like that in the days of XP, but on WIn 7+ notepad opens the file without any dot. So there's no need for that right now. This needs to be fixed.

[Usher]

2Fla$her
First, TC still supports Windows XP so your complaints about this system are null and void.
Second, it's not about opening existing file. It's a problem with CREATING and opening a new file.
Run the following command:

Code: Select all

notepad dummy

…and you can see warning that Notepad wants to create dummy.txt file.
Then run another command:

Code: Select all

notepad dummy.

…and guess what happens next.

[Fla$her]

2Usher
1. I don't have any complaints about XP. It's about having to fix this for much more popular versions. It's silly to leave a bug just to maintain an outdated version with a tiny % of users.
2. I've encountered a problem in XP before. There was such a thing. This is not a reason to leave everything as it is.

[KozakMak]

This is not a reason to leave everything as it is.

+1

[Usher]

This is not a reason to leave everything as it is.

I'm talking only about Notepad (forcing txt extension) and Windows shell (using strange rules for dot as a special character) behaviour.
Do you want to fix it? Tell it to MS coders. Don't blame TC developer - in TC there may be only workarounds.

[Fla$her]

Do you want to fix it? Tell it to MS coders. Don't blame TC developer - in TC there may be only workarounds.

Do not distort the essence. Nothing prevents the programmer from forming a condition for Windows versions with different behavior.

[white]

Lister cannot handle a trailing dot. Try for example on TC's command line:

Code: Select all

cm_List "c:\test."

Since TC 9 Lister assumes the file name really ends with a dot.

07.10.16 Fixed: Allow to view, rename and delete files ending with a dot, e.g. "test.txt .". These names are not allowed in Windows functions, but can still be created on NTFS with \\?\ prefix (32/64)

Perhaps Lister should check for both?

[ghisler(Author)]

Currently there are no plans to change this behaviour, sorry.

[Fla$her]

2ghisler(Author)
And what good is leaving such a bug?

[white]

And what good is leaving such a bug?

Agreed.

There are 2 issues mentioned in topic start:

Issue 1: Handling of Lister's filename parameter if the passed parameter ends with a dot

It's nice that since version 9.0, TC can properly view, rename and delete files in the file panel even when there are files ending with a dot. For example, if in a folder the files "file" and "file." exist, TC can properly view, rename and delete them both.

It seems this was solved by letting the internal Lister function interpret a dot at the end of a passed filename literally.
However, not only is the filename parameter interpreted this way when the Lister function is called internally, but also when Lister is called externally by using TC's command line parameter S=L or by using internal commands cm_List*.

This broke compatibility. Also, TC expects associated programs and external editors and viewers not to interpret a trailing dot literally, but TC's own Lister can no longer do so.

It would be nice if Lister supports both methods of interpreting filenames ending with a dot. Not at the same time, but each of these methods separately when explicitly chosen. Not only to solve the issue with Associations mentioned in topic start, but also when Lister is used in combination with other programs where some of these programs add a dot to the filename (when a filename doesn't have a filename extension) and others don't. This could be implemented by adding another /S=L: option.

It would also be nice if, in addition to above, the user can control whether TC adds a dot to filenames without filename extension. TC is inconsistent in that it adds a dot when calling associated programs or external editor/viewer, but does not do so when a file is dragged and dropped on a button or when TC replaces special variables like %N used in button bar etc. A solution could be to allow another modifier in the command fields, similar to the modifiers * and **. Perhaps a more flexible syntax should be introduced. For example (?<modifiers>), similar to the inline regular expression modifiers which can enable or disable certain behaviors.


Issue 2: Bug in Internal Associations when matching filenames without filename extension

Suppose there is a file named "file" on your drive. The property tc.fullname has value "file". And the string "file" is used to match against a search/file type.

If you, for example, search on the condition "tc.fullname = file" using the Plugins tab, TC finds the file.
And TC also finds the file if you search for regular expression ^[^.]+$

When defining an internal association using one of the above searches/file types, the search is done correctly to determine the icon that appears in the file list, but not to determine which program should be launched. The latter adds a dot to the filename before trying to match the filename with a file type. So in the latter case, the property tc.fullname has value "file." and no longer matches the condition "tc.fullname = file". And the filename "file." doesn't match with the regular expression ^[^.]+$

[ghisler(Author)]

Unfortunately I don't see any solution to this incompatibility.