Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Homebrew Bash completions do not work in POSIX mode #6926

Closed
cskeeters opened this issue Dec 18, 2023 · 13 comments
Closed

Homebrew Bash completions do not work in POSIX mode #6926

cskeeters opened this issue Dec 18, 2023 · 13 comments
Labels

Comments

@cskeeters
Copy link

I installed kitty (0.31.0) on MacOS (Sonoma) to try it out. I get "Homebrew Bash completions do not work in POSIX mode".

When the shell does open set | grep POS results in:

POSIXLY_CORRECT=y

If I put set +o posix as the first line in my .bashrc, there are no errors. If I use iTerm, I get no errors.

I know that the documentation indicates that POSIX is disabled before initialization scripts run, but this does not seem to be the case.

Steps to reproduce the behavior:

  1. install brew
  2. install bash completions
  3. install kitty
  4. run kitty

Environment details

kitty 0.31.0 (b247fda672) created by Kovid Goyal
Darwin arya.local 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct  9 21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000 arm64
ProductName:		macOS ProductVersion:		14.1 BuildVersion:		23B74
Frozen: True
Paths:
  kitty: /Applications/kitty.app/Contents/MacOS/kitty
  base dir: /Applications/kitty.app/Contents/Resources/kitty
  extensions dir: /Applications/kitty.app/Contents/Resources/Python/lib/kitty-extensions
  system shell: /bin/bash
Loaded config files:
  /Users/chad/.config/kitty/kitty.conf

Config options different from defaults:
allow_remote_control yes
font_size            15.0
listen_on            unix:$TMPDIR/kitty

Important environment variables seen by the kitty process:
	PATH                                /Applications/kitty.app/Contents/MacOS:/usr/bin:/bin:/usr/sbin:/sbin
	LANG                                en_US.UTF-8
	SHELL                               /bin/bash
	USER                                chad

Additional context

Running open -n /Applications/kitty.app --args --config NONE does change my font size back (which is the only thing I changed), but has no effect on this problem, or my workaround.

@cskeeters cskeeters added the bug label Dec 18, 2023
@kovidgoyal
Copy link
Owner

I have no idea what Homebrew bash completion is, or how it works, but putting the
following line at the top of ~/.bashrc

set -o | grep posix

shows that posix mode is indeed turned off before bashrc is sourced,
running kitty as

kitty --config NONE -o shell=bash

@kovidgoyal
Copy link
Owner

And just to note this is with brew install bash-completion@2 which is enabled via

cat ~/.bash_profile 
[[ -r "/opt/homebrew/etc/profile.d/bash_completion.sh" ]] && . "/opt/homebrew/etc/profile.d/bash_completion.sh"

@cskeeters
Copy link
Author

When I put set -o at the top of my .bashrc, it shows that posix is on.

Last login: Mon Dec 18 10:35:45 on ttys001
allexport      	off
braceexpand    	on
emacs          	on
errexit        	off
errtrace       	off
functrace      	off
hashall        	on
histexpand     	on
history        	on
ignoreeof      	off
interactive-comments	on
keyword        	off
monitor        	on
noclobber      	off
noexec         	off
noglob         	off
nolog          	off
notify         	off
nounset        	off
onecmd         	off
physical       	off
pipefail       	off
posix          	on
privileged     	off
verbose        	off
vi             	off
xtrace         	off

When I leave that configuration in place, but run iTerm instead of kitty, it shows off.

@cskeeters
Copy link
Author

@cskeeters
Copy link
Author

Bash completion is not the issue, it's just one thing that doesn't run correctly when the posix option is enabled.

@kovidgoyal
Copy link
Owner

As I said, I cannot reproduce. set -o | grep posix gives me posix off

@cskeeters
Copy link
Author

I found kitty.bash in /Applications/kitty.app/Contents/Resources/kitty/shell-integration/bash. At the top (under the shebang)

echo "Running bash integration"

I tried explicitly turning it on with:

shell_integration enabled

When I open kitty, set shows KITTY_SHELL_INTEGRATION=enabled. When I open up kitty, there is no output. Is it possible that the shell integration isn't running? That would explain POSIX remaining enabled if the script that runs builtin set +o posix isn't running.

I see that the program sets the ENV variable to run the integration script, but according to the bash man page, the ENV variable is only used when bash is run invoked as sh.

If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. When invoked as an interactive login shell, or a non-interactive shell with the --login option, it first attempts to read and execute commands from /etc/profile and ~/.profile, in that order. The --noprofile option may be used to inhibit this behavior. When invoked as an interactive shell with the name sh, bash looks for the variable ENV, expands its value if it is defined, and uses the expanded value as the name of a file to read and execute. Since a shell invoked as sh does not attempt to read and execute commands from any other startup files, the --rcfile option has no effect. A non-interactive shell invoked with the name sh does not attempt to read any other startup files. When invoked as sh, bash enters posix mode after the startup files are read.

Is bash being invoked as sh?

@kovidgoyal
Copy link
Owner

If shell integration is not enabled, then bash would be executed
normally and there would be no issue at all. I am guessing your problems
are caused by different bash installations on your system. Try
specifying the absolute path to the correct bash binary in kitty.conf as the
value of shell

@kovidgoyal
Copy link
Owner

And if you want to debug further run kitty from source and modify the
setup_bash_env() function. https://sw.kovidgoyal.net/kitty/build/

@cskeeters
Copy link
Author

cskeeters commented Dec 21, 2023

MacOS Sonoma ships with bash version 3.2.57(1)-release. Given that the bash shell integration script requires version 4, it won't work without a newer version of bash installed.

Users can install a newer version of bash with homebrew with brew install bash. However, kitty will only use it if you set shell=/opt/homebrew/bin/bash in ~/.config/kitty/kitty.conf. If a user does both of those things, it will work as designed. I suggest adding this to the quickstart guide for MacOS users.

NOTE: The Bash man page indicates that ENV will be used when --posix is passed as an argument. This is how kitty works since neither sh or -sh are used as arg[0]. While the bash man page[1] that comes with MacOS Sonoma also indicates that ENV should be used when --posix is passed, testing reveals that is not.

[1] https://opensource.apple.com/source/bash/bash-92/bash-3.2/doc/bash.1.auto.html and search for: "command line option, it follows the POSIX standard for startup files"

ENV=/tmp/test.sh /bin/bash --posix either has no output or script errors in a normal startup script due to POSIX mode set (i.e. Homebrew Bash completions do not work in POSIX mode) when /tmp/test.sh is :

#!/bin/bash

echo "Running"

@cskeeters
Copy link
Author

This may be useful for verification:
cskeeters@021afe1

@kovidgoyal
Copy link
Owner

The default shell on macOS is zsh not bash. If you are anyway using a
non-default shell, you should use an up-to-date version. I'm afraid
maintaining docs/code for this edge case is not worth it.

@cskeeters
Copy link
Author

Good point! I forgot that zsh is the default. I use bash a work, so I want to use the same config on my Mac. I agree that an up-to-date version should be used. Unfortunately, it's not recommended to upgrade /bin/bash as other software may depend on features or bugs in the system. That's why brew installs updated versions of bash, make, find, etc to /opt/homebrew/.

I think it's reasonable to ignore this edge case. I hope that anyone else who has this problem will find this issue.

It is fascinating that bugs like this live on for 1 or 2 decades in the interest of having "stable" software.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants