Problems with %$CLIPBOARD0% and %$CLIPNAME1%

[ghisler(Author)]

Sorry but you are expecting too much from me. I would have to manually distinguish between 100s of cases where a character would have to be converted to underscore, removed, ignored etc. etc. This would never end.

[Fla$her]

2ghisler(Author)
Don't you use regular expressions? This can be done in one go without any problems. I can demonstrate it in the script.

Even if you don't use them and find it difficult to deal with other forbidden characters, the question with quotation marks is categorical: they should be removed or replaced! Otherwise, it completely breaks the versatility, and then we will have to use only scripts.

[Dalai]

In other cases, the colon can be replaced.

I disagree. Colons are also used when separating an NTFS stream name from the file name. Something like this

Code: Select all

C:\somefile:stream_name

is a perfectly valid filename, at least on NTFS.

[Fla$her]

2Dalai
And what, for example, is supposed to be done with this path in the button, etc.?

And is it necessary to think that you agree with the rest of the remarks/requests?

If we think from this point of view, then there is no need to replace forbidden characters at all, because, for example, they are not forbidden in registry keys, i.e. we can use them to jump with the wfx plugin (cd \\\Registry\<Key>). And the resulting value is already easier to process with a script, where access to the clipboard may not be reliable enough, as in WSH.

[Dalai]

And what, for example, is supposed to be done with this path in the button, etc.?

Is it relevant what users do with valid paths?

And is it necessary to think that you agree with the rest of the remarks/requests?

I merely explained why it's not a good idea to replace colons everywhere in clipboard contents. Nothing more, nothing less.

[Fla$her]

2Dalai

Is it relevant what users do with valid paths?

Of course, it's relevant. The lower part of my post is just about this.

How is that relevant (to the point I made)?

This is relevant regardless of what you wrote before. The question is with a conclusion, given your ability to read the rest. No more, no less. If your goal is only to write remarks, and not approvals, I'll understand, no problem.

[Fla$her]

2ghisler(Author)

27.11.24 Added: New pseudo environment variables %$CLIPNAMEQ1%, %$CLIPNAME_NEQ1% etc.: Same as without "Q", but surround name with double quotes if it contains at least one space (32/64)
21.11.24 Added: New pseudo environment variables %$CLIPNAME_NE1%, %$CLIPNAME_NE2% etc.: Inserts line 1, line 2 etc. from clipboard, skipping empty lines, characters replaced like with %$CLIPNAME1%, removes leading and trailing spaces (32/64)

1. I certainly thank you for these solutions, but auto-substitution of quotation marks is not the best option, since the variable can be used in the following context:
   

   cmd /k if "%$CLIPNAME_NEQ1%"=="File Name" echo True

   
   If there are spaces, the line will look like this:
   

   cmd /k if ""File Name""=="File Name" echo True

   
   Which will lead to incorrect syntax in cmd and an error.
   If you specify a variable without quotation marks, it will lead to an error if the value is without spaces.
   
   Also, if there are no spaces, there will be a problem if there are special characters, for example, '&'.
   
   .
2. Since we initially discussed any set of whitespace characters, I decided to test it on the following command:
   

   mshta "javascript:close(clipboardData.setData('text','\f\t\n\n\n\t \t FileName \f\r\n\t\f File Name 2 \t\r\nFile Name 3\t\f\n'))"

   
   After clicking the button

   Code: Select all

   TOTALCMD#BAR#DATA
   test
   ?%|$CLIPNAME_NEQ1| %|$CLIPNAME_NEQ2| %|$CLIPNAME_NEQ3|
   wcmicon2.dll,45
   test

   instead of FileName "File Name 2" "File Name 3" I get the following result (without square brackets):

   Code: Select all

   ["   FileName"  "  File Name 2"   ]

I also ask you to answer here.

[ghisler(Author)]

auto-substitution of quotation marks is not the best option

If you always need double quotes, then just put them there yourself and don't use the Q option.

I decided to test it on the following command

It contains tabs, not spaces. My function only removes spaces.

[Fla$her]

If you always need double quotes, then just put them there yourself and don't use the Q option.

This won't fix the problem of selection with quotation marks:
" Name " > "" Name "" instead of the expected Name or "Name".
"Name" > ""Name"" instead of the expected Name or "Name".
That's why I asked you to remove the quotes so that when customizing, there would be a 100% reliable and universal option, as is the case with %P, %T, etc.

It contains tabs, not spaces. My function only removes spaces.

This is bad because there is no point or benefit in replacing outer tabs with spaces. I didn't just write about whitespace characters, which, in addition to spaces, include other specified ones.
Also, you did not pay attention to the absence of the 3rd value.

[ghisler(Author)]

Sorry, I will not remove the quotes. People may want to pass things like
"path to program\program.exe" "path to file.ext"
on a line.

[Fla$her]

2ghisler(Author)
I don't understand you. What do people have to do with it, if the absence of quotation marks gives 100% efficiency, because people can specify these quotation marks themselves?
It's the same if you initially make %P with quotation marks and say that the path can be with spaces, without even thinking about the fact that specifying quotation marks on your own will not break anything, but on the contrary, will give the only correct solution.
For example, the user has selected "C:\Program Files", and he has cd "%$CLIPNAME*%\Program folder".
What will he get? cd ""C:\Program Files"\Prorgam folder". Do you think this is normal?
Please think again about the problem, it should not be like this.

I am also waiting for an answer about the second problem.

[ghisler(Author)]

Not all people have the same needs. When I change it like this for you, it would break it for other people.

[Fla$her]

What and how can this break, explain to me, please?

If the parameter is "%$CLIPNAME*", then with or without quotation marks in the clipboard (file name or "file name" or " file name "), the parameter will return "file name". What is breaking here, I don't understand? Who can not be satisfied with this option? Show me at least one user, please.

Why doesn't %P return quotes when there are spaces? Because it can be combined with other parameters to write "%Pfile Name". So? It's exactly the same here. This is your approach, but for some reason you refuse it. This is strange.

[ghisler(Author)]

What and how can this break, explain to me, please?

I have already explained it above: People may want to pass things like
"path to program\program.exe" "path to file.ext"

Why doesn't %P return quotes when there are spaces?

It's not the same. %P returns the current path, which doesn't contains any quotes by itself. It's clearly described which parameters automatically get quotes, like %P%N.

[Fla$her]

I have already explained it above:

I didn't pay attention to the intermediate quotation marks. Sorry. But then it doesn't follow the logic of CLIPNAME*, since it's already 2 names/parameters, not one. What you have indicated should be called CLIPSTRING*. These are different things.

It's not the same. %P returns the current path, which doesn't contains any quotes by itself. It's clearly described which parameters automatically get quotes, like %P%N.

But I write about a similar approach, not the functionality itself. %P%N is already a consequence. The point is directly in the need for quotation marks.