Windows / PowerShell Functionality about gum HOT 23 CLOSED

Latest release does include Windows support now (thanks to @muesli): https://github.com/charmbracelet/gum/releases/tag/v0.10.0

I believe we can close this issue 😄

from gum.

charmbracelet/bubbletea#565 will improve the situation somewhat, as soon as we merge & bump the bubbletea dependency in gum. The redirection issues need to be addressed separately however.

from gum.

I've also figured out the redirection problem and realized it's an issue with the upstream console package printing to stdout when encountering a redirected handle. I've opened a PR here: containerd/console#66

from gum.

Windows 10 x64 user here: The problem also appears at the CMD prompt. It's not limited to Powershell.

from gum.

@michaeltlombardi Thank you so much for the really well-written issue and screen captures. It is very much appreciated.

Unfortunately, I do not have a windows machine so it is a little hard for me to debug and I have very little knowledge of how Powershell / Windows works, but I would really like for gum to be usable on Windows.

For what it's worth gum programs (interactive ones) run on stderr and then output to stdout.

Out of curiosity, does fzf work on Windows / Powershell?

from gum.

Unfortunately, I do not have a windows machine so it is a little hard for me to debug and I have very little knowledge of how Powershell / Windows works, but I would really like for gum to be usable on Windows.

Just in case nobody was aware:

You can run the latest version of PowerShell on Linux and Mac because Microsoft made it portable a while ago. Note that Windows still ships older versions of PowerShell and the terminal program (the one with the blue background which came before Windows Terminal, it's called "something host" or so), so it's up to developers and users to teach narrow minded people who deem the bare Windows OS as a sufficient OS solution that it's actually like running a recent Linux kernel with bash 2.x and KDE 3.0.x or Gnome 2.x. When you look around in the PowerShell Github organization you will find some pretty interesting things which only work with recent versions of PowerShell.

I'm just a Linux admin passing by who wrote his first few lines of PowerShell scripts to customize the OOTB experience of Windows 11 with winget and a few settings (Registry, Windows features) a few weeks ago.

from gum.

@Jonathan-Zollinger thanks for your response and the snippet

i just noticed that i had gum 0.10 & 0.8 installed

WARN  'charm-gum' (0.10.0) is already installed.
Use 'scoop update charm-gum' to install a new version.
2023-05_hot-script > gum --version
gum version v0.8.0 (dfa412f)

that is why i was confused that it was not working for me.

thank you

from gum.

I imagine the prompt mangling could be an issue with the difference between line returns on windows vs unix maybe when the gum program returns it is not printing the correct new line and that is why the prompt looks like it is not properly reset.

from gum.

Wanted to let you know that this isn't isolated to gum. I am experiencing an identical issue with a program I wrote using the bubbletea library.

https://github.com/hay-kot/gofind

Notable Things...

• I'm writing to stderr in interactive mode like fzf and returning the result to stdout
• I'm also experiencing the "failed to get console mode for stdout: The handle is invalid" as well
• Prompt is also mangled as a result
• Works fine on Mac OS

Happy to help troubleshoot on windows as well.

from gum.

I pulled down @immersivegamer fork and am still having the same issue with Gum described in the original issue. It looks like your fix implements what is more or less suggested here

• #119

I've tried modifying the code to explicitly use the handle and flag as specified in the python example in the issue, but still get the same results no matter what I've tried. Will continue to work on a fix, but I'm not super familiar with the windows APIs so It will probably take me a while.

from gum.

One more upstream fix required to correctly reset stderr on shutdown: containerd/console#67

from gum.

Any solution? Quite a downer to not have this

from gum.

@maaslalani it does!

fzf --version
fzf
$a = fzf
$a

0.32.0 (f7e7259)
gummy.txt

gummy.txt

I also tested whether fzf would handle being used in the pipeline:

(fzf) -replace '\.', '!'
(fzf) | ForEach-Object {
  $Parts = $_ -split '\.'
  [PSCustomObject]@{
    Name = $Parts[0]
    Extension = $Parts[1]
  }
} | Format-List

gummy!txt
Name      : gummy
Extension : txt

fzf seems to work okay:

• on its own (no prompt munging)
• to store the output to a variable
• to use in a subexpression ((fzf) -replace ...)
• to use in the pipeline (fzf | ...)

Taking a peek into fzf's code to see if I can find anything obvious or special they're doing to handle output on Windows now.

from gum.

Looking around, I'm not seeing too many places where they're doing Windows-specific handling.

1. func (r *Reader) feed(src io.Reader)

   Here they are chomping the CRLF instead of the LF when reading from stdin/stdout

2. func quoteEntry(entry string) string

   Here they're handling escaping strings a little differently (which I don't think is related to our issue).

3. consoleFlagsInput and consoleFlagsOutput

   It looks like they have some flag handling for Windows specifically. This gets used in func (r *LightRenderer) setupTerminal() error and func (r *LightRenderer) restoreTerminal() error which might be a clue, but I'm not super clear on how that changes things yet.

4. This line might be important at some point as it interacts with the virtual terminal input for PSReadLine which will almost always be loaded in a modern interactive PowerShell session. Though looking at the PR it was added (back) in I don't think the issue it was resolving is one bubbletea or this project has.

from gum.

3. consoleFlagsInput and consoleFlagsOutput

   It looks like they have some flag handling for Windows specifically. This gets used in func (r *LightRenderer) setupTerminal() error and func (r *LightRenderer) restoreTerminal() error which might be a clue, but I'm not super clear on how that changes things yet.

4. This line might be important at some point as it interacts with the virtual terminal input for PSReadLine which will almost always be loaded in a modern interactive PowerShell session. Though looking at junegunn/fzf#2580 I don't think the issue it was resolving is one bubbletea or this project has.

Just to add to these. When using gum and then doing a tail using Get-Content I am unable to use Ctrl-C or Ctrl-Break to stop the running process, I have to shut down the PowerShell process. This seems to point to an issue with the SetConsoleMode that was seen in num. 4 and the combination of flags in num. 3. I am guessing something in gum changes the console mode when reading input and doesn't revert it.

Reading input is the key to the above. If I do:

gum style "Hello"
> Hello
Get-Content -Tail 0 -Wait C:\temp\log.txt
> # can succesfully use ctrl-c (^C) to stop

However, if I use choose, input, or filter before the tail I cannot quit:

$path = (Get-ChildItem C:\temp\ -File -Filter *.txt).Fullname | gum filter
> chose item
$path = $path[1].Trim() # hack for the extra error as commented already by the original poster
Get-Content -Tail 0 -Wait $path
> # cannot use ctrl-c to stop

I tested with a different program that keeps on running instead of running Get-Content, I was able to use Ctrl-C to exit it. So my guess it is something to do with ENABLE_VIRTUAL_TERMINAL_INPUT flag when running in the context of PowerShell.

I tested this on Windows PowerShell v5.1 and PowerShell v7 on Windows 10. I may try testing gum with PowerShell on a non-windows machine.

from gum.

I can't say I know the first thing about this topic and I apologize if this is just noise, but I remember that Taskfile uses https://pkg.go.dev/mvdan.cc/sh/v3 under the hood to smooth out variances between OSes and shells. Of course it introduces at least another dependency and I'm not sure if this aligns with the intentions of the authors...

from gum.

This was way harder than I would have thought to figure out. Had to bang my head against how to get the console stream input on Windows. Couldn't just use stdin since it can sometimes be a pipe (e.g. when using gum filter). This change is at least working for me personally on PowerShell v7 on Windows 10. It solves my problem of not being able to use Ctrl-C after certain gum UI runs. I'll be using my personal forked version. I would clean it up for integration but I'm tapped out for a while. Maybe someone else can pickup where I left off: immersivegamer@6577304

from gum.

Will removing console dep completely help with powershell issues?

from gum.

came here to say I'm finding the same issue when piping variable assignments from gum filter on powershell 7 on windows 11

from gum.

My upstream fixes have been merged, so pretty much all of this is working fine now.

from gum.

@maaslalani I hate to be that guy.. but it does not work in Cygwin 😭😭😭

Powershell confirmed working

from gum.

@maaslalani the issue still perists for me in PowerShell 7.2.11

and the error failed to get console mode for stdout: The handle is invalid. remains.
do you have any ideas why or tipps for me?

appreciate your help

from gum.

@alexn-s if you're experiencing the same thing as i am, the the value returned is actually multiple strings. see my gif below - I've thought about how I'd go about this between now and when I first ran into it in february (prior to the fix in build 0f0f8e9).

to show what I'm seeing when I use gum input as you showed, I'm calling gum input then piping it to a foreach ternary which then uses an expression to print the returned strings wrapped with green text to emphasize the string separations.

gum input \
  --placeholder "Tell me something nice." | % { echo "$(gum style --foreground="#00fff" "String in series of strings ->") $_ $(gum style --foreground="#00fff" "<-- end of String")" }

This is what I see:

if you're experiencing the same thing, then maybe you could add an eleement to your script to remove any Strings that match the error message?

that being said, ultimately the best case would be to update to v0.10.0 - that fixed it on my end (if you used scoop, it's just scoop update charm-gum)

from gum.