Run an interactive bash subshell with initial commands without returning to the ("super") shell immediately

This can be easily done with temporary named pipes:

bash --init-file <(echo "ls; pwd")

Credit for this answer goes to the comment from Lie Ryan. I found this really useful, and it's less noticeable in the comments, so I thought it should be its own answer.

Try this instead:

$> bash -c "ls;pwd;other commands;$SHELL"

$SHELL It makes the shell open in interactive mode, waiting for a close with exit.

You can do this in a roundabout way with a temp file, although it will take two lines:

echo "ls; pwd" > initfile
bash --init-file initfile

Why not use native subshells?

$ ( ls; pwd; exec $BASH; )
bar     foo     howdy
/tmp/hello/
bash-4.4$ 
bash-4.4$ exit
$

Enclosing commands with parentheses makes bash spawn a subprocess to run these commands, so you can, for example, alter the environment without affecting parent shell. This is basically more readable equivalent to the bash -c "ls; pwd; exec $BASH".

If that still looks verbose, there are two options. One is to have this snippet as a function:

$ run() { ( eval "$@"; exec $BASH; ) }
$ run 'ls; pwd;'
bar     foo     howdy
/tmp/hello/
bash-4.4$ exit
$ run 'ls;' 'pwd;'
bar     foo     howdy
/tmp/hello/
bash-4.4$ exit
$

Another is to make exec $BASH shorter:

$ R() { exec $BASH; }
$ ( ls; pwd; R )
bar     foo     howdy
/tmp/hello/
bash-4.4$ exit
$

I personally like R approach more, as there is no need to play with escaping strings.

What you need is to execute a startup script, then proceed with the interactive session.

The default startup script is ~/.bashrc, another script could be given with the --init-file option. If you simply pass an --init-file option, your script would replace the default, rather than augment it.

The solution is to pass, using the <(...) syntax, a temporary script that sources the default ~/.bashrc followed by any other commands:

bash --init-file <(echo ". ~/.bashrc; ls; pwd; ### other commands... ###")

The "Expect solution" I was referring to is programming a bash shell with the Expect programming language:

#!/usr/bin/env expect
set init_commands [lindex $argv 0]
set bash_prompt {\$ $}              ;# adjust to suit your own prompt
spawn bash
expect -re $bash_prompt {send -- "$init_commands\r"}
interact
puts "exiting subshell"

You'd run that like: ./subshell.exp "ls; pwd"

If sudo -E bash does not work, I use the following, which has met my expectations so far:

sudo HOME=$HOME bash --rcfile $HOME/.bashrc

I set HOME=$HOME because I want my new session to have HOME set to my user's HOME, rather than root's HOME, which happens by default on some systems.

less elegant than --init-file, but perhaps more instrumentable:

fn(){
    echo 'hello from exported function'
}

while read -a commands
do
    eval ${commands[@]}
done

I accomplish basically the same thing by just using a script, typically for the purpose of setting environment variables for use in a specific project directory;

$ cat shell.sh
#!/bin/bash
export PATH=$PWD/bin:$PATH
export USERNAME=foo
export PASSWORD=bar
export DB_SERVER=http://localhost:6001
bash

$ echo ${USERNAME:-none}
none

$ ./shell.sh

$ echo $USERNAME
foo

This drops you into an interactive bash shell after all the environment adjustments are made; you can update this script with the relevant other commands you want to run.

$ bash --init-file <(echo 'ls; pwd')
$ bash --rcfile <(echo 'ls; pwd')

In case you can't use process substitution:

$ cat script
ls; pwd
$ bash --init-file script

With sh (dash, busybox):

$ ENV=script sh

Or:

$ bash -c 'ls; pwd; exec bash'
$ sh -c 'ls; pwd; exec sh'