ignored null byte in input when Warpify docker bash

[Alex-EEE]

Dupe Check

• I have searched Warp bugs and there are no duplicates

Describe the bug

After an upgrade to the latest version, I now see this when I Warpify /bin/bash running in a docker container (x86 linux)

bash: warning: command substitution: ignored null byte in input
bash: warning: command substitution: ignored null byte in input
bash: warning: command substitution: ignored null byte in input
... over and over

To reproduce

docker run ... /bin/bash
Warpify subshell
type anything into prompt

Expected behavior

not this

Screenshots

No response

Operating system

MacOS

Operating system and version

Sonoma

Shell Version

GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

Current Warp version

v0.2024.11.19.08.02.stable_01

Regression

Yes, this bug started recently or with an X Warp version

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[alokedesai]

Hey @Alex-EEE, sorry for the issues and thanks for filing. What version of bash are you using in this docker container? Could you share the contents of your bashrc/bashprofile?

[haohanyuzmx]

you can reproduction with docker run -it --rm ubuntu:22.04 bash

[um-jglad]

I am also seeing this after updating to v0.2024.11.19.08.02.stable_01 and using a warpified subshell on remote systems, so not docker but same issue. If I'm able to use ssh it appears to not be a problem, but this isn't possible on all of my remote machines.

Local

• macOS 15.1.1 (24B91)
• zsh 5.9 (arm64-apple-darwin24.0)
• warp version v0.2024.11.19.08.02.stable_01
• warpified subshell

Remote

• RedHat & Rocky
• GNU bash, version 4.4.20(1)-release (x86_64-redhat-linux-gnu)

[dannyneira]

Hey folks, I'm having trouble reproducing on ARM Macs or Intel Mac.

Does adding the following to your remote/docker ~/.bashrc files help?

printf '\eP$f{"hook": "SourcedRcFileForWarp", "value": { "shell": "bash"}}\x9c'

Also, can you please provide your logs.

zip -j ~/warp-logs.zip ~/Library/Logs/warp.log*

[Alex-EEE]

I have an ARM Mac, but I was emulating x86 with Rosetta (maybe do the same to repro?)

[um-jglad]

I am running an ARM (m3) Mac, connecting to remote linux systems.

Adding the following line in my remote .bashrc did not have any affect, so it seems to have something to do with the 'warpification' of subshells. Again, using ssh works as intended, but command ssh > ctrl + i produces the error.

warp-logs.zip

Thanks!

[sutibu]

me too. I have the same local and remote env as @um-jglad . Adding the line to .bashrc does NOT FIX this issue.

[alokedesai]

Hi folks, we're actively looking at this issue and should have an update shortly.

[alokedesai]

Hey all, we're still actively investigating and hope to have a new update in the next day or two. If you are blocked by this, you can download last week's release here:
https://releases.warp.dev/stable/v0.2024.11.12.08.02.stable_02/Warp.dmg

[Alex-EEE]

thanks for the update, I'll grab the older version!

[scottaw66]

Please let us know when it's safe to click that "Update Warp" button again 😄 Thank you!

[alokedesai]

Hey everyone, thanks for your patience here. The latest version of Warp should have a fix for this. Please let me know if you are still seeing problems!