powershell core installations are creating desktop symlinks that breaks PSReadLine w. garbage chars

I just installed the latest PowerShell 7.2.0-preview.2 and yet again the pwsh link that appear on desktop has the classic broken command line garbage, as reported in several places (see #11685 and issues repos within) .

So I copied the old link I had, from and for pwsh 6.1.1, and modified it to be exactly the same (as above) as far as its adjustable in the file properties. The result is that the old link with new paths is working perfectly! Going through some link forensics from here I noticed that the two symlinks are different by ~40 bytes and by structure. This is only visible by hexedit/hexdump and not even the lnkinfo.exe forensic tool.

So unlike what was previously believed, this does not seem to be a PSReadLine issue.

The real question now, is why symlinks are created differently for the installers in the last 1.5 years?

Steps to reproduce

• Install latest powershell
• Open desktop terminal shell
• type anything

Expected behavior

No pwsh terminal cmd line garbage

Actual behavior

shows broken ctrl characters

$ s [104m

Environment data

$  $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.1.1
PSEdition                      Core
GitCommitId                    6.1.1
OS                             Microsoft Windows 6.3.9600
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

and

-----------------------------------------------------------------------
  PowerShell Version    : 7.2.0-preview.2
  OS Name               : Microsoft Windows 8.1 (64-bit)
  OS Version            : 6.3.9600  [2014-08-16 00:50:01]
  OS BuildLabEx         : 9600.19880
  OS HAL                : 6.3.9600.18969
  OS Kernel             : 6.3.9600.18217
  OS UBR                : 19893
  -------------------------------------------------------
  on Host               : xxxx
  as User               : xxxx
  with Privilege        : Normal
  -------------------------------------------------------
  ExecutionPolicy:
      MachinePolicy     : Undefined
      UserPolicy        : Undefined
      Process           : Undefined
      CurrentUser       : Bypass
      LocalMachine      : RemoteSigned

  Firewall:
      Status            : OK

  Console Settings:
      Type              : ConsoleHost
      OutputEncoding    : Unicode (UTF-8)
      Color Capability  : 151
      Registry VT Level : 1
      CodePage (input)  : 437
      CodePage (output) : 437
      Mode (input)      : N/A
      Mode (output)     : N/A
      Buffer Size (W H) : 150 9009
      PSReadLine version: 2.1.0-beta2

---

Alternatively

Create a new symlink with Powershell using:

$ New-Item -ItemType SymbolicLink -Path C:\Users\xxxx\Desktop\pwss -Target "C:\Program Files\PowerShell\7-preview\pwsh.exe"

$ Get-ChildItem C:\Users\xxxx\Desktop\pwss | fl

    Directory: C:\Users\xxxx\Desktop

Name           : pwss
Length         : 0
CreationTime   : 2020-12-22 19:54:21
LastWriteTime  : 2020-12-22 19:54:21
LastAccessTime : 2020-12-22 19:54:21
Mode           : -a---l
LinkType       : SymbolicLink
Target         : {C:\Program Files\PowerShell\7-preview\pwsh.exe}
VersionInfo    : File:             C:\Users\xxxx\Desktop\pwss
                 InternalName:     pwsh.dll
                 OriginalFilename: pwsh.dll
                 FileVersion:      7.2.0.0
                 FileDescription:  pwsh
                 Product:          PowerShell
                 ProductVersion:   7.2.0-preview.2 SHA: 47ef533b2edd5f4cfae5adb9533613f142dc4315
                 Debug:            False
                 Patched:          False
                 PreRelease:       False
                 PrivateBuild:     False
                 SpecialBuild:     False
                 Language:         Language Neutral

That is also broken.

The same info for the old (modified symlink for pwsh preview ) that is working, is:

 $ Get-ChildItem C:\Users\xxxx\Desktop\pwsh7b.lnk | fl

    Directory: C:\Users\xxxx\Desktop

Name           : pwsh7b.lnk
Length         : 1716
CreationTime   : 2020-12-22 05:33:18
LastWriteTime  : 2020-12-22 05:36:06
LastAccessTime : 2020-12-22 05:33:18
Mode           : -a----
LinkType       :
Target         : {}
VersionInfo    : File:             C:\Users\xxxx\Desktop\pwsh7b.lnk
                 InternalName:
                 OriginalFilename:
                 FileVersion:
                 FileDescription:
                 Product:
                 ProductVersion:
                 Debug:            False
                 Patched:          False
                 PreRelease:       False
                 PrivateBuild:     False
                 SpecialBuild:     False
                 Language:

Unfortunately, this seem to be a more general problem, as it is not clear why these symlinks are looking so different.

1. Are they even symlinks?
2. Why doesn’t the working links show the type as a symlink?
3. Why are the link target not reported?

The lnkinfo.exe tool is not able to read the New-Item created SymbolicLinks… While looking at them in Cygwin, the seem more like a cygwin softlink, reporting:

# \ls -lh pwss
lrwxrwxrwx 1 Administrators None 55 Dec 22 19:54 pwss -> /cygdrive/c/Program Files/PowerShell/7-preview/pwsh.exe

The same issue occurs, for any new “terminal” type of links. For example the Anaconda created one’s have the same issue.

[DHowett]

Speaking as the owner of both conhost and the Windows Terminal (both of which are open-source), I’d like to clear up a few misconceptions.

conhost … [legacy] … [not supported]

We’re avoiding the term “legacy” for the console host. It is an important and foundational part of Windows, and it is not becoming unsupported. It underpins all console applications, even inside Windows Terminal.

The product here that is unsupported is Windows 8.1. It predates almost all of our conhost changes, from VT support to word wrap to all of the allocation and memory and performance improvements. That version of Windows will not be receiving any further conhost or Terminal updates¹.

Symbolic links don’t matter at all in this case.

There is a bug in Windows that results in an application launched from a symbolic link being told that it was launched from a shell link (!) whose path is the symbolic link (!) ². This may confuse some applications. This confuses conhost in a way that causes it to treat “L” or “F” as a hotkey (globally!) that will give the launched console window focus.

[some stuff about colors]

Windows PowerShell made a [what should arguably be considered significant] mistake when it shipped and permanently redefined colors 5 and 6, as well as the default foreground/background colors, using its in-box lnk file. This is not normal, and should not be relied on. The color indices are fairly unyielding, and using the “powershell default” colors will cause you trouble literally everywhere else.

Open-source PowerShell fixed this.

ConsoleDataBlock … undocumented

Here’s the source for the part of conhost that reads the shell link and pulls properties out of it. Our source is our documentation in many regards.

Escape character garbage … [hex editing my shortcut file]

I doubt it would ever be fixed as it’s a fundamental problem with how conhost deals with console output.

Nothing stored in the shortcut file will ever change the VT parsing behavior on Windows 8.1. That functionality does not exist in conhost.exe as of Windows 8.1. An application such as powershell emitting VT sequences to a console host that doesn’t support it is an application bug.

(@jborean93) This is not a “fundamental problem,” it is a feature that was implemented in the seven years since Windows 8.1 shipped.

Where exactly are these colors specified for default created windows shortcuts and SymbolicLinks?

Default settings are all here. The campbell color table is here.

Shell links by default have no color information. If your shell link doesn’t have a console block, settings are loaded in the order @jborean93 described.

¹ Rumor has it that a build of conhost from our open-source repository (OpenConsole, “Host.EXE”) will run on Windows 8.1. YMMV. NO WARRANTY, EXPRESS OR IMPLIED. If it runs, it will support all modern console features from Windows 10.

² This will result in the application opening an executable as a lnk file and attempting to parse it. Not awesome.

[jborean93]

Are they even symlinks?

I have no idea what the issue is but a .lnk file is a shortcut file and not a symbolic link. This is why the LinkType is empty and it has no target. Technically a shortcut does have a target but PowerShell hasn’t implemented support for getting the target. You would need to use COM to achieve that.

The simple way is

$shell = New-Object -ComObject ("WScript.Shell")
$shortcut = $shell.CreateShortcut('C:\my\shortcut.lnk')
$shortcut.TargetPath

Unfortunately this method does not support all shortcut targets. It will probably work in this case but there are times when TargetPath will be blank yet the shortcut does have a target path. To get the proper path you need some more complex C# code like what Ansible uses https://github.com/ansible-collections/community.windows/blob/main/plugins/modules/win_shortcut.ps1.

You could always just see the path by looking at the file properties in explorer though.