I've tested it. If I use "!P", the double quote is escaped correctly.

It's a problem with having a double quote in the string. Use the example to see the problem.

I'm not sure I understand the problem.

user564758 wrote:

If i use just !P i get this result.

"¬`¦!"£$%^&*()_+{}~[]#:@;'<>?,./|\"

If you use just !P, you should get no quotes around the value. And actually, it makes little sense to use any placeholder without quotes.

Well thanks for considering it but there is still the bug/issue with double quotes that maybe should be treated separately.

For example this password cannot be used with "!P" as the double quote in the password breaks the way WinSCP handles quoting the string.



If i use just !P i get this result.



But as i mentioned this now breaks paths with spaces.

Can you please look into that as a potential bug?

Please see here to view how i am using it via a bash function

https://github.com/userdocs/LFTP4WIN-CORE/blob/master/system/scripts/functions.sh#L75-L93

That passes it to openssh.

https://github.com/userdocs/LFTP4WIN-CORE/blob/master/system/applications/winscp/winscp_openssh.WinSCPextension.sh

This is more functional than the kitty integration as it cannot handle this kind of password.

OK, I will see, if more people ask for this.

I'll try to explain the problem and why have a fully encoded version of the expansions might be useful.

Let's say i have a remote path on Linux like this, it has both single and double quotes in the path.



Or a password like this:



Or a local path like this:



When "!/" is used with the above remote path I cannot pass this onto anther program as the double quotes cause a conflict. WinSCP will behave differently with this URL. for example, using my custom command via an extension - https://github.com/userdocs/LFTP4WIN-CORE/blob/master/system/applications/winscp/winscp_lftp.WinSCPextension.sh

I can use this URL if i do not wrap the expansion in a double quote. WinSCP seems to escape this automatically but does not expand the result surrounded by quotes.



Will return this result ( with no double quotes at the start or end)



But if i now try this same unquoted expansion with a more basic path:



Whatever checks WinSCP has in place to escape the complex URL seems to miss this and i get result like this with no double quotes surrounded the result:



Where as this quoted command will return the correct simple path but break the complex path:



You see the result is wrapped in double quotes:



So whilst this may highlight a potential bug in how and when WinSCP escapes what it really shows is how the solution is to provide an encoded version, for example.

With a password like this:



I simply cannot pass this to bash in any way using this command as the expansion of !P breaks the script by having double quotes and the last character technically escaping any other quotes once expanded when using this command format.



But if i do this instead to get the password from the session URL, where $4 is !S:



I can now pass on and reuse the password in anyway i need and only decode it as and when required without any real problems.

Conclusion:

If WinSCP could provide a URL encoded or base64 encoded version of the key expansions:



These could easily be passed to bash or other third party application without having any double quote, single quote or backslash expansion conflicts and allow proper re-use of the variables by having them decoded locally for reuse as and when needed.
I hope this explains the problem i have experienced.

But WinSCP escapes the double quotes in file names.

If all the required variables could be passed as encoded strings then i could pass them around and work with them however i needed. Currently the double quote method works (unless it's a remote path with a double quote in the path for example) but makes it harder to pass that variable to another application. (like openssh)

Currently !P is problematic for passwords with single or double quotes when passing to bash

Complex remote and local paths behave differently if they have quotes in the path.

So, if there was an option to have all the variables fully encoded before they are passed like !S does, that would actually be really useful. I pass them to bash cygwin/conemu via a function to interpret the WinSCP expansions.

There's no such pattern.
What special characters do you have an issue with? "!" should work.

Local Command, Remote flag.

I would like to be able to get the remote path to a file or folder and have it encoded as per this right click method. (it automatically encoded special characters)



So that the result of the command pattern is like this.



Is there a way to do this that i am missing?

Reason:

I am passing these to bash and the only way i can make sure the any special character in the path is not an issue is if i can get it from WinSCP in the encoded format and process it in bash manually.