Warp
Warp copied to clipboard
warpdotdev
Stop stdout from background job from bleeding into editor
Discord username (optional)
No response
Describe the bug
If a background job is tailing a file, the output of that affects all ENTER commands.
To Reproduce
Run this in warp and give it 2 seconds to start writing to file:
bash echo_to_file.md &
Then run
tail -f /tmp/t &
Now all stdout from that file will make its way into the edit input so all ENTER commands will fail when you are trying to do something else.
Expected behaviour
Possibly have a button when output is incoming from outside background jobs, when clicked, you can view it? This is better than just throwing invalid commands for all the stdout being flushed inside the terminal.
Screenshots
No response
Operating System
MacOS
OS Version
12.4
Shell Version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin21) Copyright (C) 2007 Free Software Foundation, Inc.
Warp Version
latest... you guys took out the copy button
Additional context
No response
Does this block you from using Warp daily?
Yes
Warp Internal (ignore): linear-label:b8107fdf-ba31-488d-b103-d271c89cac3e
No response
@davidrenne. We're so sorry to hear you're having this issue. I will bring this up with the team and post any updates on status of a fix here.
As a stopgap, I found that if you run the tail -f /tmp/t without the & at the end it doesn't affect other tabs, only the tab running the tail -f command.
Alternatively, if you need to use the & at the end of the tail command, you can open a new Warp window with CMD-N, and the new window won't be affected by the running tail either.
__ Danny Neira (he/him/his) Support Engineer www.warp.dev
@warpdotdev-dx, yea I know I can use a new tab. Its just that other terminals basically flush out the logs to my terminal of the logs of a background job, but allow me to enter in commands without using the stdout of a background job into my buffer of new commands.
Something to think about though with background jobs writing into your "command entry form", that is very strange behavior that warp has. I wonder why the code is wired up that way that output from a background job is being interpreted as something a person is typing in. It's very strange architecture.
@warpdotdev-dx , note I believe this also happens when you are not tailing a file. I have another process that runs a webpack job in the background and I saw this happen to me in that scenario too.
This bug is really nasty and frustrating.
Encountered this during some work with fly.io proxy:
fly proxy 5432 -a my-db &
# the output of this background job somehow ends in the editor for the next command, instead of being appended in the output of the previous command.
Yep exactly @carlosbaraza any other standard terminal does not take background output and injects that into your buffer to send.
I've had warp physically wrote files in my cwd because of the crazy commands it's trying to send. Also probably sometimes appends all these crazy commands to your history
I think I'm seeing similar behavior in my case. Have a bash function that, among other things, runs a kubectl port-forward ... in the background via &, and at the end does a cleanup via kill %<job-id>. After completion, I see the command bleed into the next block. If I just press Enter, it tries to execute it and fails. Have to Ctrl+C to exit it.
# Last step in bash function
$ kill -9 "%$kport_jid" || true
In Warp:
The above function runs fine in the standard MacOS Terminal.
Warp version: v0.2022.10.11.08.13.stable_01
$ sw_vers
ProductName: macOS
ProductVersion: 12.3
BuildVersion: 21E230
@warpdotdev-dx, three devs is a party.... it happens to me every day i just let it run bad commands and i have to CTRL+C to stop it from executing more from the background job stdout.
Hey Folks, this is being worked on and on the roadmap. No ETA on a fix, but we're working on it. 🚀
Thank you. This is really a buggy UX, and together with scrolling limits (disappearing lines at the beginning), the only quirks that stop me from loving Warp.
@davidrenne the only thing that keeps me is the AI completion, which works pretty well for common CLI tasks.
Looks like a security issue too. I wouldn't be surprised if someone was able to exploit this.
With every new warp release, I hope this issue is solved. But no luck so far.
@elviskahoro we have 6 unique developers talking about this issue being important. What is the status on this? Why not just open source warp to let the community fix it?
We'll hopefully have something you can opt in to test this week or next! Working on a few known rough edges with the implementation before that goes out.
Hey all! We've got a build of Warp with improvements to how it handles typeahead and background output for you to try out:
- Run
defaults write dev.warp.Warp-Stable EnableTypeahead 'true' - Download Warp here: https://storage.googleapis.com/warp-releases/stable/v0.2023.04.25.08.05.stable_00/Warp.dmg
- Warp will try to auto-update to the current release, downgrading and removing these changes. Make sure not to update until next week
Let us know what you think!
Unfortunately, I have found that the above warp version with the EnableTypeahead option set to be true causes constantly high CPU load.
Thanks for flagging that @dpolivaev! The next Warp release should have a fix
@bnavetta Thanks, I installed the latest version. I had to activate the option again, it seems that it is not active by default yet, and I am going to observe how it works.
@dpolivaev the fix is available in the latest Warp!
My version reports that it is up to date and I still see this behavior. Is the fix in a beta or dev version?
@dpolivaev the fix is available in the latest Warp!
My version reports that it is up to date and I still see this behavior. Is the fix in a beta or dev version?
What do you mean by "this behavior"? High CPU load or the output from the background job?
To activate the feature you currently need to run defaults write dev.warp.Warp-Stable EnableTypeahead 'true'
My warp version where the feature works as I expect is v0.2023.05.02.08.03.stable_00
@bnavetta so that's great the feature is in the prod build when you enable it. But when will it be enabled by default. Once enough of the community finds no issues I hope? Cause it isn't really a desired feature to just keep out in the wild making people angry and having bad user experiences.
Exactly, we're hoping to enable it for everyone soon, once we're confident there aren't any major issues lingering
Hi everyone, this is enabled-by-default in Warp as of v0.2023.05.09.08.03.stable_01. We've got some documentation on how it works here: https://docs.warp.dev/features/blocks/background-blocks. Closing for now, but let us know if there are any further issues!
This is amazing. Good job everyone. Warp is really becoming a great terminal.