-
-
Save skyline75489/480d036db8ae9069b7009377e6eebb79 to your computer and use it in GitHub Desktop.
function prompt { | |
$p = $($executionContext.SessionState.Path.CurrentLocation) | |
$converted_path = Convert-Path $p | |
$ansi_escape = [char]27 | |
"PS $p$('>' * ($nestedPromptLevel + 1)) "; | |
Write-Host "$ansi_escape]9;9;$converted_path$ansi_escape\" | |
} |
I've only just noticed these gists now, and I see you guys have already got this figured out. So you can probably ignore a lot of my comments on the PR. The only thing I think worth mentioning is that we'd ideally be applying URL escaping to the path name. I know that's not going to be possible in the cmd.exe shell, but I'm assuming it might be achievable with PowerShell.
@j4james I get your point. But on Windows, Neither \
nor /
is valid character in a path. So perhaps there's no real need for URL escaping? I'm no expert at this. Hope some Win32 dude could help with this.
As noted on the main ticket, we can use [system.uri]
in PowerShell to deal with escaping for us. I'm not sure if we can say "Just generate a legacy filesystem path URL" or if we have to feed it something like [system.url](file://${env:COMPUTERNAME}/$p.ProviderPath)
, but either way escaping is not our problem.
There are a few characters that are legal in a Windows path but not in a URI path. %
is the most obvious one, but there's also #
. There may be others, depending on how strict the parser is. I would also have expected non-ascii characters to be escaped to avoid issues with different code pages.
Yup, it supports that fine. Although I didn't create these directories.
PS C:\Users\paulh> [system.uri]("C:\dog%\cat#\mousewords")
AbsolutePath : C:/dog%25/cat%23/mousewords
AbsoluteUri : file:///C:/dog%25/cat%23/mousewords
LocalPath : C:\dog%\cat#\mousewords
Authority :
HostNameType : Basic
IsDefaultPort : True
IsFile : True
IsLoopback : True
PathAndQuery : C:/dog%25/cat%23/mousewords
Segments : {/, C:/, dog%25/, cat%23/…}
IsUnc : False
Host :
Port : -1
Query :
Fragment :
Scheme : file
OriginalString : C:\dog%\cat#\mousewords
DnsSafeHost :
IdnHost :
IsAbsoluteUri : True
UserEscaped : False
UserInfo :
PS C:\Users\paulh> [system.uri]("C:\mẹ\母")
AbsolutePath : C:/m%E1%BA%B9/%E6%AF%8D
AbsoluteUri : file:///C:/m%E1%BA%B9/%E6%AF%8D
LocalPath : C:\mẹ\母
Authority :
HostNameType : Basic
IsDefaultPort : True
IsFile : True
IsLoopback : True
PathAndQuery : C:/m%E1%BA%B9/%E6%AF%8D
Segments : {/, C:/, m%E1%BA%B9/, %E6%AF%8D}
IsUnc : False
Host :
Port : -1
Query :
Fragment :
Scheme : file
OriginalString : C:\mẹ\母
DnsSafeHost :
IdnHost :
IsAbsoluteUri : True
UserEscaped : False
UserInfo :
Although I didn't create these directories.
AbsolutePath : C:/dog%25/cat%23/mousewords
If it wasn't you, there's a strong indication that your cat may have been responsible.
Ah, nice find on
Convert-Path
.And now you've got me looking, I discovered the joy of PSProviders, the things that let you
cd HKLM:\Software\Microsoft
to access the registry.I assume that for OSC 7 we only want the
FileSystem
provider, because anything else would be pretty insane. I haven't tested it with in-box Microsoft PowerShell, just PowerShell Core. I'm assuming the PSProvider Name is stillFileSystem
there.I also turned the
\
into/
for general URL sanity, and got rid of the Write-Host, since that made testing it a bit messy.So this is what I have now:
That said, I haven't seen how this interoperates with the PR yet.