[kitty, Atuin] clone-in-kitty+eval "$(atuin init bash)" throw syntax error

[gvlassis]

$ ble summary
GNU bash, version 5.2.37(1)-release (aarch64-apple-darwin24.0.0)
ble.sh, version 0.4.0-devel4+3d8f626 (noarch) [git 2.45.2, GNU Make 4.3, GNU Awk 5.3.0, API 4.0, (GNU MPFR 4.2.1, GNU MP 6.3.0)]
atuin, version 18.4.0 (/Users/gvlassis/.local/bin/atuin)
locale: LANG=en_US.UTF-8 LC_GEM=sapphire
terminal: TERM=xterm-kitty wcwidth=16.0-west/16.0-2+ri, kitty:0 (1;4000;39)
options: +inherit_errexit +login_shell

Hello!

I recently noticed that, in my setup, doing clone-in-kitty throws -bash: 1737470736163691 - : syntax error: operand expected (error token is "- ") when I have eval "$(atuin init bash)" on my .bashrc.

My .bashrc looks like this:

# At the top, to properly pick up the bind and trap settings
. "${HOME}/.local/share/blesh/ble.sh" --noattach

# Commenting this line fixes the issue
eval "$(atuin init bash)"

# Shell-integration script here
if [ "${TERM}" = "xterm-kitty" ]; then
    . "${HOME}/.local/share/kitty.bash"
fi

# At the bottom
ble-attach

Commenting out eval "$(atuin init bash)" fixes the issue, but disables atuin.

[akinomyoga]

I could reproduce the problem, but this is not an issue of ble.sh. The problem also happens with bash-preexec + atuin + clone-in-kitty.

# bashrc
source /path/to/bash-preexec.sh
eval "$(atuin init bash)"
if [ "${TERM}" = "xterm-kitty" ]; then
    . /path/to/kitty.bash"
fi

[akinomyoga]

My .bashrc looks like this:

...

# Shell-integration script here
if [ "${TERM}" = "xterm-kitty" ]; then
    . "${HOME}/.local/share/kitty.bash"
fi

Is this part needed? As far as I test, kitty automatically loads this shell-integration setting even if you don't source it in ~/.bashrc by yourself. You can turn off the automatic loading by setting shell_integration disabled in ~/.config/kitty/kitty.conf, but clone-in-kitty doesn't work in that case. Thus, I think you anyway need to turn on the automatic loading of kitty's shell integration, so you don't need to source it manually. In fact, I can reproduce the problem even without manually sourcing kitty.bash. With this two-line ~/.bashrc, the reported problem reproduces:

# bashrc
source /path/to/bash-preexec.sh
eval "$(atuin init bash)"

---

What is happening is that clone-in-kitty overwrites Atuin's environment variable ATUIN_HISTORY_ID, which is specific to the current Atuin session, with the value of ATUIN_HISTORY_ID in the original session. In particular, after Atuin initializes its ATUIN_HISTORY_ID to a proper value inside eval "$(atuin init bash)", kitty overwrites it with the wrong value. Then, Atuin misunderstands that it is still in a session where clone-in-kitty is run and tries to calculate the time duration of the command clone-in-kitty, which fails and causes the reported error message.

[akinomyoga]

I'm not sure what would be the best solution to this, but I guess it would be probably having a kitty option to specify the list of environment variables that should not be copied.

[akinomyoga]

I realized that the upstream kitty actually maintains a hardcoded black list of the environment variables, so I submitted PR kovidgoyal/kitty#8275 to the upstream to add known environment variables that are used by frameworks but should not be cloned to another shell session. The PR was merged now.

[gvlassis]

Hello!

Sorry for the very late reply! I had a conference deadline I needed to meet, and life got in the way.

Is this part needed? As far as I test, kitty automatically loads this shell-integration setting even if you don't source it in ~/.bashrc by yourself. You can turn off the automatic loading by setting shell_integration disabled in ~/.config/kitty/kitty.conf, but clone-in-kitty doesn't work in that case. Thus, I think you anyway need to turn on the automatic loading of kitty's shell integration, so you don't need to source it manually.

If you have shell_integration enabled in kitty.conf, no, you do not need this snippet. The reasons I prefer manually sourcing it are that:

1. (To a great extend thanks to a very illuminating previous discussion with you) I know what is supposed to be happening behind the scenes, and there is no reason for me to depend on automatic functions (in the sense that this is more dependable)
2. I used to have problems with the vscode integration script (I do not use it any more), and this part fixed it. So, it is a habit I picked up then.
3. clone-in-kitty (and everything really) works with the manual sourcing (I know you know it, but I mention this for future reference/other users)

What is happening is that clone-in-kitty overwrites Atuin's environment variable ATUIN_HISTORY_ID, which is specific to the current Atuin session, with the value of ATUIN_HISTORY_ID in the original session. In particular, after Atuin initializes its ATUIN_HISTORY_ID to a proper value inside eval "$(atuin init bash)", kitty overwrites it with the wrong value. Then, Atuin misunderstands that it is still in a session where clone-in-kitty is run and tries to calculate the time duration of the command clone-in-kitty, which fails and causes the reported error message.

Makes absolute sense. It continues to amaze me how fast and to the point you solve problems like these. And how clearly you communicate your findings/the solutions. It is truly inspiring.

I realized that the upstream kitty actually maintains a hardcoded black list of the environment variables, so I submitted PR kovidgoyal/kitty#8275 to the upstream to add known environment variables that are used by frameworks but should not be cloned to another shell session. The PR was merged now.

This is absolutely the best solution. I wish I had the time/knowledge to do it myself. Next time 😉.

I tested the latest kitty version (0.39.1), and this is indeed fixed!

I also want to encourage everyone to donate to this amazing project (I just donated 10$ more myself). Not only is it immensely useful, it is also lead by a developer that... Well, I do not need to describe it. Just look at how he conducts himself, and how he replies to people having problems.

[akinomyoga]

Thank you for testing the behavior in the latest version of kitty! Thank you also for those encouraging words!

3. clone-in-kitty (and everything really) works with the manual sourcing (I know you know it,

Ah, actually, I didn't know that.

As far as I try, if I have shell_integration disabled in kitty.conf and source kitty's shell-integration file manually, it doesn't define the shell function clone-in-kitty. I checked what happened. It seems that the kitty shell integration cancels itself on this line because the shell variable KITTY_SHELL_INTEGRATION is undefined when kitty's automatic shell-integration is disabled. Maybe what you source is different from the file I source.

Then, I checked what kitty's manual says. The manual integration section explains the following setting:

if test -n "$KITTY_INSTALLATION_DIR"; then
    export KITTY_SHELL_INTEGRATION="enabled"
    source "$KITTY_INSTALLATION_DIR/shell-integration/bash/kitty.bash"
fi

where KITTY_SHELL_INTEGRATION is set before sourcing the shell integration file (which is not told in the original post). My current guess is that your "${HOME}/.local/share/kitty.bash" is actually a custom file that contains the above four lines (or equivalent codes).