0

My login shell is Fish, but I would like to execute a shell command (apt install ...) as if my login shell was Bash.

Is it possible to make a command/subprocess believe that my login shell is /usr/bin/bash without actually making it my login shell?

Here is the context. When I try to install a certain package with apt install, the post-installation script fails to start some service, and there is an error message from fish about wrong syntax:

fish: Variables cannot be bracketed. In fish, please use "$XDG_RUNTIME_DIR". XDG_RUNTIME_DIR="/run/user/$UID" DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTI ME_DIR}/bus" systemctl --user start gpa 

I tried executing apt install from Bash, but this did not help. However, if I change my login shell to Bash, then the installation succeeds without errors.

Of course, I do not want to change the login shell back and forth to execute one command, I hope there is a more appropriate solution. (Of course, I do not understand why the post-installation script blindly uses the login shell which is not good for it.)


P.S. The package I was installing is GlobalProtect_deb-6.2.1.1-7.deb for Palo Alto GlobalProtect VPN. Some versions are available online, for example here: https://myport.port.ac.uk/connect-to-the-vpn-on-your-linux-device

5
  • 2
    That is one broken package. No package should be looking at any detail of a normal user, let alone their login shell. Can you include the part of the postinst script which causes the error, then we could see how best to fake the shell it needs? Commented May 24 at 14:24
  • @muru, this is Palo Alto GlobalProtect VPN, in fact. I was wondering if there is some general workaround. I am not sure I want to dig into the package: after all I can change the login shell back and forth (or reboot to start the service). Commented May 24 at 14:36
  • 1
    The appropriate thing to when some installer does something stupid would be to complain to the developers, especially so when it's something you or your company is paying for. There usually isn't a general workaround for such things, ref: goodreads.com/quotes/… But if you don't want to change the login shell, you can use a mount namespace to make it see a fake /etc/passwd, say, but that wouldn't be any easier. Or if you can show what it specifically is doing that causes the error, we can try to find other workarounds. Commented May 24 at 14:43
  • 2
    SHELL=/bin/bash your-command might be all that is needed. Doesn't change your login shell but that's the variable that commands usually check to know which is your preferred shell. It's itself initialised from your login shell. Commented May 24 at 14:45
  • @StéphaneChazelas, just tried prepending SHELL=/usr/bin/bash while executing from Bash. Did not help. I suppose I should follow the advice of @muru and complain somewhere... Commented May 24 at 14:50

2 Answers 2

3

If the faulty maintainer script looks at the SHELL environment variable to find the login shell, override that:

SHELL=/bin/bash apt install … 

Alternatively, if your root user still has a non-fish shell as its login shell, login using that for commands that need to run as root:

sudo -i apt install … 

This runs the target user’s shell (root’s shell here) as a login shell to run the command.

3
  • Strangely, neither of the two worked. Even though if I execute sudo -i without arguments, I am in bash. Commented May 24 at 14:59
  • @Alexey that’s surprising! The maintainer script must be doing something rather unusual... Is the package publicly available? Commented May 24 at 15:09
  • @StephenKitt, it seems to be "more or less" publicly available, see here, for examples: myport.port.ac.uk/connect-to-the-vpn-on-your-linux-device . The package that I was installing is GlobalProtect_deb-6.2.1.1-7.deb. Commented May 24 at 15:14
2

I searched around and found a deb file for this software at https://terpware.umd.edu/Linux/Package/4811. Checking the postinst file extracted from that deb file, I find:

 if [ "$USE_SYSTEMD" ]; then if [ -n "$SUDO_USER" ]; then echo "start GPA for sudo user $SUDO_USER" | tee -a $LOG su -c 'XDG_RUNTIME_DIR="/run/user/$UID" DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus" systemctl --user start gpa' $SUDO_USER elif [ -n "$LOGIN_USER" ] && [ "$LOGIN_USER" == "$EFFECT_USER" ]; then # login user is root echo "start GPA for effect $EFFECT_USER" >> $LOG systemctl --user start gpa & >> $LOG elif [ -n "$LOGIN_USER" ] && [ "$LOGIN_USER" != "$EFFECT_USER" ]; then # su echo "start GPA for login $LOGIN_USER" >> $LOG su -c 'XDG_RUNTIME_DIR="/run/user/$UID" DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus" systemctl --user start gpa' $LOGIN_USER echo -e "\033[1;33mWarning:\033[0m Please switch back to user $LOGIN_USER before you run globalprotect." | tee -a $LOG else # $LOGIN_USER is unknown. Ask for reboot echo -e "\033[1;33mWarning:\033[0m GlobalProtect was installed. Please reboot your machine to bring it up." | tee -a $LOG fi 

It sets USE_SYSTEMD using USE_SYSTEMD="$(pidof systemd || echo '')", so that one's hard to fake. But for SUDO_USER, you could do:

sudo env SUDO_USER=<some-other-user> apt install ... 

Now the question is: which user can you use? There's no point in enabling this for root. Most other system users have /usr/sbin/nologin as their shell. In this postinst file, set -e at the top was commented out, so an error probably doesn't actually cause problems (which I think is confirmed by your question only saying that this error is shown, but not that the installation fails). So you could sub in any random system user, say:

sudo env SUDO_USER=nobody apt install ... 

Then you'd get just this message instead:

This account is currently not available. 

Thinking a bit more on this, you could also make a fake su just for this:

#! /bin/bash /bin/su -s /bin/bash "$@" 

Save it as an executable file named su at, say, $HOME/bin-for-broken-packages/su, and then run:

sudo env PATH="$HOME/bin-for-broken-packages:$PATH" apt install ... 
1
  • 1
    Interesting, thanks. Not sure I will apply this in practice, but I'll try to understand how it works. Commented May 24 at 15:21

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.