[9.51] Character ^ in filename is not correctly recognize by TC command line parameters %N

[realgy]

To be precise, if a filename contains Character ^ but does not contain any of these four Characters "space = & !", then this fimename will not be recognized correctly by the TC command line parameters %N, Character ^ in the filename will be omitted.

For example, if the selected filename is 1^2.txt, it is recognized as 12.txt by the TC command line parameters %N.
However, if the file name also contains any of these four characters "space = & !", Chsaracter ^ will be recognized correctly.

The reason is that the filename is automatically double-quoted by TC command line parameters when it contains these four characters "space = & !". If the special characters are in double quotes, they are correctly recognized by TC command line parameters.

So far, a filename contains Character ^ is not yet automatically double-quoted by TC command line parameters, so it is still not correctly recognized by TC command line parameters.

I found this when I made some toolbar buttons. I would appreciate it if it would be fixed.

[MVV]

Actually it is cmd.exe who treats '^' character as an escape character (but ignores it in quoted strings), you can check process command line and ensure that TC passes filename properly. You can face same problem while writing a batch file.
TC fault is only that it does quote only names that contain some special characters, not all names.

[gdpr deleted 6]

2MVV
Despite cmd.exe's horrible rules with regard to command line arguments, the problem here is not with cmd.exe.
cmd.exe demands a string/file name to be quoted if it contains special characters such as the circumflex.

From cmd.exe's own documentation:

Code: Select all

The special characters that require quotes are:
     <space>
     &()[]{}^=;!'+,`~

And %P%N does not quote if a file/directory name contains a circumflex but no other special character, which is entirely and solely a problem with TC.


Look closely at the command line shown in TaskManager when you use a file name like "1^2.txt" for a %P%N argument in a toolbar button with a batch file:

Code: Select all

C:\Windows\system32\cmd.exe /c ""X:\test.cmd" X:\1^2.txt"

Note that the file path argument itself is not quoted, which is not correct.

It should rather have quotes around the file path like this:

Code: Select all

C:\Windows\system32\cmd.exe /c ""X:\test.cmd" "X:\1^2.txt""

Now compare this with a file name like "1&2.txt":

Code: Select all

C:\Windows\system32\cmd.exe /c ""X:\test.cmd" "X:\1&2.txt""

Note that this time the file name argument IS quoted.


Screenhot from my TaskManager process list showing toolbar button invocations once with 1^2.txt and once with 1&2.txt: https://imgur.com/a/3evcvXR



You can actually get the the example with the file 1^2.txt kind of "working" by just surrounding %P%N with quotes in the button definition. This is of course not a feasible workaround due to %P%N auto-quoting paths where it deems it necessary (and unfortunately missing to look for "^"), but it will demonstrate that the problem indeed seems to be with TC.

[MVV]

It is a special cmd.exe feature to treat ^ character not like regular characters, like other special characters.
BTW there is also a problem with e.g. directory paths and MSVC-compiled programs where stupid CRT treats \" sequence in a quoted string as an escaped " character so you can't just pass "%P" to such programs because trailing backslash will escape closing quote.
TC can't be aware of all such peculiarities.

But, as I said, specifically this one could be solved by just quoting all names in %P%N w/o analysing them.

[gdpr deleted 6]

But, as I said, specifically this one could be solved by just quoting all names in %P%N w/o analysing them.

I agree. This should be the easiest and safest way to solve the problem.

[realgy]

Actually it is cmd.exe who treats '^' character as an escape character (but ignores it in quoted strings), you can check process command line and ensure that TC passes filename properly. You can face same problem while writing a batch file.
TC fault is only that it does quote only names that contain some special characters, not all names.

Thanx for reply . There is also a special character '&'. Actually, there are only two special character '&' and '^' in filenames cannot be correctly passed to batch files or programs by SendTo in Context Menu of System. But TC has solved one of them, the characters '&'.

The point is the strategy of double-quoting filenames:

SendTo of System only quotes filenames contain space. But TC is different, TC quotes filenames contain any of these four characters 'space = & !'. Look, '&' is included in them, so '&' has indeed been resolved in TC parameters.

[ghisler(Author)]

Why not add quotes yourself around the paramters? TC only adds quotes when a file name contains spaces, so it's not broken into multiple parameters. This is needed by all apps to open files with spaces. TC doesn't check whether the target app follows any special rules handling these parameters.

[gdpr deleted 6]

Why not add quotes yourself around the paramters?

Because

TC [...] adds quotes when a file name contains spaces, so it's not broken into multiple parameters.

If the button defintion contains "%P%N" with quotes and TC itself adds another pair of quotes when the file name contains spaces, the command line again is broken into multiple pieces.

Also, i have to disagree with you. If you check my first comment above, it doesn't seem true that TC _only_ adds quotes if a path contains spaces. There are clearly quotes when the path contains an ampersand, for example, which are missing if the path does not contain any special characters.

[MVV]

ghisler(Author),
Using "%P%N" is not an option as elgonzo said, also it won't work with %S or similar.
I think you can absolutely safely make %P%N and other single-item parameters always quoting, and there should be an INI option to always quote %S and other multi-item parameters, and it should be enough safe to set it to 1 by default (ones who pass often lots of files via %S can disable it - but I don't think that there are many users who do so because it is much more realiable to гse %L in such case).

[sqa_wizard]

Support++ for always quoting %P%N to have a reliable format without bothering about blanks or special characters included or not!

[ghisler(Author)]

If you add quotes yourself around %P%N, then TC will not add extra quotes by itself when the name contains spaces.

[gdpr deleted 6]

If you add quotes yourself around %P%N, then TC will not add extra quotes by itself when the name contains spaces.

No, it does not work. TC will still insert its own pair of quotes if it encounters a file name/path with a space or other special character except the ^, even if i add quotes around %P%N or %N. But %P%S and %S behave like you described.

Is this perhaps a regression? (I only tested the current TC 9.51)

[MVV]

Hm-m, would be a nice feature with all of argument sequences: %P%N, %T%M, %S, %P%S etc.

Currently it isn't documented anywhere and:
+ works with "%P%S", though there is a note in help telling me do not do this: "Do NOT put quotes around %P%S yourself";
- "%P%N" still inserts its own quotes making path invalid, e.g.: ""D:\1 2.txt"".

So as a workaround one may use "%P%S1" as an always quoting %P%N.

[gdpr deleted 6]

So as a workaround one may use "%P%S1" as an always quoting %P%N.

Using S1 instead of N may be a workaround. Or it may not be, as the behavior of these two differ if there are one or more files selected:

S1 - first of the selected files
N - file under cursor

[MVV]

You're right, %P%S1 and %P%N return different files in case of a selection!

But there is an exact %P%N analog without quoting, %P%O.%E, so "%P%O.%E" gives the same file as %P%N but always quoted.