fc echoes back starship_preexec "$_"

hmenke commented 3 years ago

Current Behavior

Bash supports editing the command line using fc. However, when inserting a command that way the contents of the DEBUG trap are echoed back.

user in ~ took 2s 
❯ sleep 2 && echo Hello Starship
Hello Starship

user in ~ took 2s 
❯ fc # this starts $EDITOR
sleep 2 && echo Hello Starship
starship_preexec "$_"
starship_preexec "$_"
Hello Starship

Expected Behavior

It shouldn't make a difference whether the command is entered at the prompt or with fc. Both should result in the same output.

user in ~ took 2s 
❯ sleep 2 && echo Hello Starship
Hello Starship

user in ~ took 2s 
❯ fc # this starts $EDITOR
sleep 2 && echo Hello Starship
Hello Starship

Additional context/Screenshots

N/A

Possible Solution

I have only found this related link with the same problem but no solution there either: https://stackoverflow.com/questions/12363901/how-to-use-debug-trap-without-echoing-trap-command-in-fix-command

Environment

Starship version: 0.44.0
bash version: GNU bash, version 4.4.23(1)-release (x86_64-unknown-linux-gnu) Copyright (C) 2016 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.

Operating system: NixOS 20.09.2190.78dc359abf8
Terminal emulator:

Relevant Shell Configuration

eval "$(starship init bash)"

Starship Configuration

<unknown config>

socketbox commented 3 years ago

Confirming that this is also evident in Starship 0.50.0

underrun commented 2 years ago

sumbled on this using <ctrl-x><ctrl-e> to open my current command in an editor which does what looks like the same thing as fc with hisotry (which i didn't know existed before and is very cool).

I use this feature frequently and it'd be really grate to have it work.

❯ starship --version
starship 0.58.0
tag:v0.58.0
commit_hash:0a60d1e9
build_time:2021-09-21 13:43:49 +00:00
build_env:rustc 1.55.0 (c8dfcfe04 2021-09-06),

chipbuster commented 2 years ago

@underrun I can't seem to reproduce this with a starship setup on 0.58 and bash. What version of bash are you running, and do you have any other shell frameworks loaded?

underrun commented 2 years ago

I'm using bash 4+ - whatever is default on Ubuntu 20.04

No I'm only using starship.

This also happens if i use vi mode via readline and hit v from command mode to enter visual mode for editing the command line in vim.

chipbuster commented 2 years ago

@underrun Thanks for the info. I was able to reproduce under the default bash and the issue went away when using a locally-compiled copy of bash 5.1. I'm going to assume this means that it's either fixed in bash 5.1 or that there's some set of flags in-use for the standard builds which makes this issue come up.

While I don't have time to debug this in-depth at the moment, I have the following trace from running under set -x if anyone wants to examine it further:

Bash Trace Here

``` ❯ set -x +++ starship_preexec -x +++ local PREV_LAST_ARG=-x +++ '[' false = true ']' +++ : -x ++ starship_precmd ++ STARSHIP_CMD_STATUS=0 ++ STARSHIP_PIPE_STATUS=(${PIPESTATUS[@]}) ++ [[ 0 -gt 1 ]] ++ local NUM_JOBS=0 +++ jobs -p ++ : ++ eval '' ++ [[ -n 1634623131978 ]] +++ /usr/local/bin/starship time ++ STARSHIP_END_TIME=1634623131981 ++ STARSHIP_DURATION=3 +++ /usr/local/bin/starship prompt --status=0 --pipestatus 0 --jobs=0 --cmd-duration=3 ++ PS1=' \[\]~\[\] \[\]❯\[\] ' ++ unset STARSHIP_START_TIME ++ STARSHIP_PREEXEC_READY=true ~ ❯ ls +++ starship_preexec -x +++ local PREV_LAST_ARG=-x +++ '[' true = true ']' +++ STARSHIP_PREEXEC_READY=false ++++ /usr/local/bin/starship time +++ STARSHIP_START_TIME=1634623135759 +++ : -x +++ command -v editor ++ fc -e /usr/bin/editor ++++ starship_preexec -x ++++ local PREV_LAST_ARG=-x ++++ '[' false = true ']' ++++ : -x +++ /usr/bin/editor /tmp/bash-fc.e8KklQ ls -l starship_preexec "$_" ++++ starship_preexec /tmp/bash-fc.e8KklQ ++++ local PREV_LAST_ARG=/tmp/bash-fc.e8KklQ ++++ '[' false = true ']' ++++ : /tmp/bash-fc.e8KklQ +++ ls --color=auto -l total 32 drwxr-xr-x 2 chip chip 4096 Oct 18 18:34 Desktop drwxr-xr-x 2 chip chip 4096 Oct 18 18:34 Documents drwxr-xr-x 3 chip chip 4096 Oct 19 00:53 Downloads drwxr-xr-x 2 chip chip 4096 Oct 18 18:34 Music drwxr-xr-x 2 chip chip 4096 Oct 18 18:34 Pictures drwxr-xr-x 2 chip chip 4096 Oct 18 18:34 Public drwxr-xr-x 2 chip chip 4096 Oct 18 18:34 Templates drwxr-xr-x 2 chip chip 4096 Oct 18 18:34 Videos ```

The second command is modified with ^X^E using nano on the system.

chipbuster commented 2 years ago

In that thread, the author seems to agree that this is a bug in 4.4 and 5.0, and that the 5.1 alpha seems to fix it (which is consistent with my testing on Ubuntu 20.04, where installing the 5.1.0 release seemed to fix the issue). Since the liquidprompt people weren't able to find a workaround, I'm going to go ahead and flag this as upstream and tentatively say that there's no known workaround.

If anyone can find a bash prompt that uses the DEBUG trap and PROMPT with commands, and doesn't have this issue, I would be interested in studying it to figure out how that's accomplished, but as of right now, I'm afraid the only surefire way to fix this is to disable the DEBUG trap (thus disabling command timing information in bash) or by upgrading to 5.1+

starship / starship