So I explain the confusion with the solution I used here on Github based on your example, so thanks for that.


When using this example session URL the password gets special characters encoded (i think is url-encoded) %241111111111111%40


So what I was originally asking was if entire session could have an option to be URL encoded the same way to avoid the issue. That seemed to cause some misunderstanding about my encoding comment.

Based on your example I made this bash solution to base64 encode the entire !S string instead of changing ; to _


So by doing this I don't get the error in windows terminal and I just base64 decode the output in my bash script.

This is what I wanted from my original comment but your PowerShell example just showed me how I could do it.

So thanks, I hope this clears the confusion and helps anyone else if they need it.

I do not see any misunderstanding. Though I do not understand "So the point is that is !S was encoded like !P" – !P is not encoded anyhow.

Anyway, I've shown you in my previous post, how to implement the "encoding".

I think there is a misunderstanding about why think encoding is an option to me. All I want, essentially, is do this


So in my particular use case passing the password with a semicolon is fine because I decode this positional parameter via a function


So the point is that is !S was encoded like !P or had the option to be encoded, maybe for all session parameters, it could be passed as I just showed and then decoded by the bash script extension to be used.

That so why having it encoded would work for me here. Otherwise I would need to mediate. I hope this makes sense to why I think maybe having an option to encode this or maybe all session vars could be useful.

The encoding cannot work. The point of the encoding is to encode the characters in passwords (and similar) parts of the URL that have otherwise special meaning to WinSCP. If you encode the semicolon, it would become part of the password. It would have to be yet another kind of encoding. But that can be hardly universal. Every app have different special characters.

But the "mediator" would indeed work. Either wrap your final command/script to yet another script. Or use the !`command` pattern. For example:

And then in your final extension script, reverse the replacement/encoding.

The only thing I can think WinSCP can do is encode the entire string like it does with passwords or provide an option to do it. If it was encoded I could decode it client side in my script.

Otherwise I guess the fix has to be at their end. Like a flag to ignore ;

Or use a mediator (cmd/bash) that opens wt after the string is processed instead of trying to pass it directly to wt

OK, I see. What do you suggest WinSCP should do about it? I didn't find a way to escape the semicolons in Windows Terminal commandline. Is there? If not, it's something you should ask them to do.

It's nothing to do with bash really, this is a Windows Terminal problem and there are other posts here about Windows Terminal mangling semi colons.

The password one is encoded but this session URL is not and the semi colon is causing Windows Terminal to split the output.

Can you please share more details? I do not understand the connection to bash and Windows Terminal.

I am passing !S via an extension file and there is a semicolon in the result that is confusing Windows Terminal



I am passing it to bash.exe and it splits the positional parameters at fingerprint=ssh-ed25519-MYKEY@IP