$env:XDG_SESSION_TYPE seems to be defined here: https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html#type= & https://www.freedesktop.org/software/systemd/man/latest/sd_session_get_type.html#, deep in the systemd man pages they host. I'm not personally sure if this means that they are "official" or just "there".

We could also instead check for the presence of $env:WAYLAND_DISPLAY, which (should hopefully) always be set.

pam_systemd

sd_session_is_active

$env:XDG_SESSION_TYPE seems to be defined here: https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html#type= & https://www.freedesktop.org/software/systemd/man/latest/sd_session_get_type.html#, deep in the systemd man pages they host. I'm not personally sure if this means that they are "official" or just "there".

We could also instead check for the presence of $env:WAYLAND_DISPLAY, which (should hopefully) always be set.

pam_systemd

sd_session_is_active

yah - that was more about systemd (and it doesn't look like much it's going to be incorporated into the mainline specs)

I was thinking that a flexible approach would be along the lines of a PowerShell variable, which could provide for more subtle behaviors. Please don't focus on the names, just the flexibility of the approach.

$PSClipboardActions = @{
     Clip = @{
        Command = "your clipper here"
        Arguments = "-l","-otherparameter"
     }
     Paste = @{
        Command = "your paster here"
        Arguments = "-param1","-param2"
     }
}

There's no real reason it has to be an environment variable either, as this sort of thing is happening in an interactive session. Also, this approach would work for all platforms.

Since freedesktop doesn't seem to be moving forward in this area, we shouldn't necessarily be bound by it. It seemed to me that the systemd was an initial foray into the arena (and seems to be inconsistently implemented).

I suppose the above could be extended to be a scriptblock to evaluate at runtime which clipboard stuff you want, which might enable clip-stacks and even more flexibility. Encapsulating all that in a simple string might be pretty tricky :)

pam_systemd

sd_session_is_active

The @PowerShell/wg-powershell-cmdlets discussed this, we see 3 areas of interest pertaining to this issue:

• Detection of Wayland should use the WAYLAND_DISPLAY env var rather than relying on the XDG_SESSION_TYPE which is owned by OpenDesktop where Wayland currently doesn't play a role
• We agreed that to provide flexibility and be more future proof, it makes sense to expose a PowerShell variable for cut and paste as Jim proposes
• Then it makes sense to simplify the clipboard cmdlets to use this PowerShell variable and thus the detection code (including Wayland) for setting defaults to the PowerShell variable should reside in the engine which would also allow other tools to use these variables

We also defer to the Interactive WG to discuss this proposal

Hi, I'm currently trying my best to see what code should go where, so progress is slow (along with more sudden busyness)

On Windows, the clipboard is set using Windows-specific code, not a command like clip. How should I handle this?
On Windows, the clipboard is handled internally, not through a command like clip.exe. I had a few ideas on how I should handle it, but none of these seem great to me:

1. A third field in the $PSClipboardAction variable, which is checked. If true, Clip and Paste are ignored

$PSClipboardActions = @{
	Clip = @{ UseInternalWindowsThing = $true }
	Paste = @{ UseInternalWindowsThing = $true }
}

2. New class that will specifically hold all these options in constructors like ClipboardActions(string), ClipboardActions(string, string[]), ClipboardActions(bool), where $PSClipboardActions is modified in-shell like

# one string
$PSClipboardActions = @{
	Clip = [ClipboardActions]::new("wl-copy"); # <-- runs "<input> | wl-copy"
	Paste = [ClipboardActions]::new("wl-paste");
}

# string, string[]
$PSClipboardActions = @{
	Clip = [ClipboardActions]::new("xclip", @("-selection", "clipboard", "-in")); # <-- runs "<input> | xclip -selection clipboard -in"
	Paste = [ClipboardActions]::new("xclip", @("-selection", "clipboard", "-out"));
}

# bool ?
$PSClipboardActions = @{
	Clip = [ClipboardActions]::new($true); # <-- uses the Windows stuff already in Microsoft.PowerShell.Commands.Internal.Clipboard
	Paste = [ClipboardActions]::new($true);
}

but I feel like this reads poorly (in my uninformed opinion). Any ideas?

The WG Interactive agrees with the @SteveL-MSFT plan.

Also: this is untested on Windows since I don't want to go through the hassle of installing VS2019, but setting Clip/Paste to @{UseWindowsClipboard=$true} does show the correct exception text, so it's probably okay

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author