sgleizes / xsh Goto Github PK

I have a weird case where xsh breaks the usage of rbenv, pyenv and nodenv installation extensions (ruby-build, python-build, node-build.
The tools throw weird download errors and can't install a ruby, python or node version.
I tracked this issue down to this specific line in the _xsh_load_unit function.
The reasons seems to be the handling of spaces in a command executed from a script.
the build-node script constructs a curl invocation like this

curl -q -o node-v16.13.0-darwin-x64.tar.gz -sSLf    "https://nodejs.org/dist/v16.13.0/node-v16.13.0-darwin-x64.tar.gz"

See the spaces before the URL argument. These spaces come from some string interpolation with empty values.

see:
https://github.com/nodenv/node-build/blob/cf03552c03fb7908ff79c13e3bf55207c057c447/bin/node-build#L445

It's the CURL_OPTS variable which results by default in a string with two spaces.

If I change the mentioned block in _xsh_load_unit to this code everything works fine for me:

  {
    oldIFS="$IFS"
    IFS=":"
    set -o noglob
    set -- $XSH_SHELLS
    set +o noglob
    IFS="$oldIFS"
  }

I didn't quite understand why the parameters need to be reset in this function. For me the XSH_SHELLS variable only ever contains a single entry which is the current shell.

I'm running:

OS: macOS 11.6
bash: GNU bash, version 5.1.12(1)-release (x86_64-apple-darwin20.6.0)
zsh: 5.8 (x86_64-apple-darwin19.6.0)

I will test this on my arch linux box as well and see if I have the same error.

Regarding Bash, I have configurations in /etc/bash.bashrc that I used as pre-configs before ~/.bashrc for regular users as well as configs for root user (interactively). Now when I enter in Bash non-login interactively with some user account, this file gets sourced first before xsh. In there, there's also these lines that came with the distro (Arch):

[[ $- != *i* ]] && return

[[ $DISPLAY ]] && shopt -s checkwinsize
[ -r /usr/share/bash-completion/bash_completion   ] && . /usr/share/bash-completion/bash_completion

My question is, how could I organize this with xsh? I'm looking for a fresh start with separate configs for root and regular users. Should I just delete this file and put everything in the @interactive.bash runcom or would it cause problems? Should I instead make a xsh directory for root user and just copy this file to its interactive runcom?

Same question goes with the /etc/profile file which came with more complicated code, including the umask and functions accessible to /etc/profile.d:

# Set our umask
umask 022

# Append "$1" to $PATH when not already in.
# This function API is accessible to scripts in /etc/profile.d
append_path () {
    case ":$PATH:" in
        *:"$1":*)
            ;;
        *)
            PATH="${PATH:+$PATH:}$1"
    esac
}

# Append our default paths
append_path '/usr/local/sbin'
append_path '/usr/local/bin'
append_path '/usr/bin'

# Force PATH to be environment
export PATH

# Load profiles from /etc/profile.d
if test -d /etc/profile.d/; then
        for profile in /etc/profile.d/*.sh; do
                test -r "$profile" && . "$profile"
        done
        unset profile
fi

# Unload our profile API functions
unset -f append_path

# Source global bash config, when interactive but not posix or sh mode
if test "$BASH" &&\
   test "$PS1" &&\
   test -z "$POSIXLY_CORRECT" &&\
   test "${0#-}" != sh &&\
   test -r /etc/bash.bashrc
then
        . /etc/bash.bashrc
fi

# Termcap is outdated, old, and crusty, kill it.
unset TERMCAP

# Man is much better than us at figuring this out
unset MANPATH

I'm unsure if moving this or the /etc/bash.bashrc will break things, but if possible I'd rather have this in @login runcoms for separate users, would it be possible to delete it and just copy its contents? Should I just copy it without deleting, or maybe a hardlink or maybe don't do anything and make changes only to the ~/.bash_profile @login runcom? I'm looking for advices on how to deal with these /etc/ configs, for Bash and the /etc/zshenv, /etc/zsh/profile configs.

module runcom in $XSH_CONFIG_DIR/<shell-variant>/<module>/ not loded, when you set XSH_RUNCOM_PREFIX=. in ~/.bash_profile, ~/.profile, etc..

MacBook-Pro:~ techdragon$ xsh bootstrap
+ [bash] creating directory: /Users/techdragon/.config/shell/bash
+ [bash] linking shell runcoms
ln: illegal option -- -
usage: ln [-Ffhinsv] source_file [target_file]
       ln [-Ffhinsv] source_file ... target_dir
       link source_file target_file
ln: illegal option -- -
usage: ln [-Ffhinsv] source_file [target_file]
       ln [-Ffhinsv] source_file ... target_dir
       link source_file target_file
ln: illegal option -- -
usage: ln [-Ffhinsv] source_file [target_file]
       ln [-Ffhinsv] source_file ... target_dir
       link source_file target_file
ln: illegal option -- -
usage: ln [-Ffhinsv] source_file [target_file]
       ln [-Ffhinsv] source_file ... target_dir
       link source_file target_file
+ [bash] creating default init file: bash/init.bash
+ [bash] creating default module runcom: bash/core/@interactive.bash

That illegal option looks like failure due to not using the GNU tools but the BSD ones.

One tactic I've used is to use platform detection in combination with function wrappers, by assignment of the correct function wrapper to the function used throughout the code in order to allow workarounds and alternative options to be used to support BSD coreutils, or alternative commands in the case of homebrew coreutils... this will ensure that its possible to get the necessary functionality is provided regardless of the OS and coreutils in use.

I'm writing this up for my own needs, since I want cross platform use, ideally with actual BSD coreutil support, but I also want to get up and running sooner, so I'm building a 'needs homebrew installed coreutils on macos' version of this functionality that I'm happy submitting as a PR. I also intend to add annotations with respect for shellcheck as I find it invaluable in keeping my shell scripting from accidentally using non-posix behaviour without knowing it.