Shell scripts, no matter how they are executed, execute one command after the other. So your code will execute results.sh after the last command of st_new.sh has finished.

Now there is a special command which messes this up: &

cmd &

means: "Start a new background process and execute cmd in it. After starting the background process, immediately continue with the next command in the script."

That means & doesn't wait for cmd to do it's work. My guess is that st_new.sh contains such a command. If that is the case, then you need to modify the script:

cmd &
BACK_PID=$!

This puts the process ID (PID) of the new background process in the variable BACK_PID. You can then wait for it to end:

while kill -0 $BACK_PID ; do
    echo "Process is still active..."
    sleep 1
    # You can add a timeout here if you want
done

or, if you don't want any special handling/output simply

wait $BACK_PID

Note that some programs automatically start a background process when you run them, even if you omit the &. Check the documentation, they often have an option to write their PID to a file or you can run them in the foreground with an option and then use the shell's & command instead to get the PID.

You'll want to use the wait command to do this for you. You can either capture all of the children process IDs and wait for them specifically, or if they are the only background processes your script is creating, you can just call wait without an argument. For example:

#!/bin/bash
# run two processes in the background and wait for them to finish

nohup sleep 3 &
nohup sleep 10 &

echo "This will wait until both are done"
date
wait
date
echo "Done"

If I create a BASH script using

$ cat > blah
#!/bin/bash
read
ls

Make it executable using chmod

chmod +x blah

Then run it

$ bash blah 
-- script has stopped as i type this, it will continue on enter
bionic                        focal-desktop-amd64.iso            kde_neon                                  zsync_disco.sh
blah                          focal-desktop-amd64.iso.zs-old     qa_query.py                               zsync_eoan.sh
eoan-desktop-amd64.iso        focal-desktop-amd64.iso.zsync      qatracker.py                              zsync_focal.sh
eoan-desktop-amd64.iso.zsync  focal-desktop-amd64.iso.zsync.old  siduction-patience-lxqt-amd64-latest.iso

The script runs and pauses waiting for the read to complete. I type the text "-- script has stopped as i type this, it will continue on enter" and press Enter.

Then and only then (when read has completed) does the ls command execute.

I could add a "&" to the end of the read line so it ran in the background and thus ls would continue without waiting.. but what you want is actually the default.

You're already doing it.

Waiting for a command to finish is the shell's normal behavior. (Try typing sleep 5 at a shell prompt.) The only time that doesn't happen is when you append & to the command, or when the command itself does something to effectively background itself (the latter is a bit of an oversimplification).

You can delete the wait %% command from your script; it probably just produces an error message like wait: %%: no such job. (Question: does it actually print such a message?)

Do you have any evidence that the tar command isn't completing before the /home/ftp.sh command starts?

Incidentally, it's a bit odd to have things other than users' home directories directly under /home.

(I know most of this was already covered in comments, but I thought there should be an actual answer.)

While wait -n (per comment @icarus) works in this particular situation, it should be noted that$! contains the PID of the last process that is started. So you could test on that as well:

#!/bin/bash

find $HOME/Downloads -name "dummy" &
p1=$!
find $HOME/Downloads -name "dummy" &
p2=$!
find $HOME/Downloads -name "dummy" &
p3=$!
while true
do
    if ps $p1 > /dev/null ; then
        echo -n "p1 runs "
    else 
        echo -n "p1 ended"
    fi
    if ps $p2 > /dev/null ; then
        echo -n "p2 runs "
    else 
        echo -n "p2 ended"
    fi
    if ps $p1 > /dev/null ; then
        echo -n "p3 runs "
    else 
        echo -n "p3 ended"
    fi
    echo ''
    sleep 1
done

But parallel is a better option.

No. The screen -X stuff command will return immediately, because it is not aware that it is being asked to run a command in the first place, even more so when that command is complete – all it's doing is injecting keypresses (which is why you had to add the ^M manually). As soon as the fake tty input has been sent, the command returns and your script continues.

In general, as a terminal emulator, screen does not know what exactly is happening in any specific terminal window – there's nothing that would delimit a shell prompt (or any other interactive console prompt) from regular output.

(This is not fundamentally impossible – some terminal emulators allow the shell to output "output start/end" and "prompt start/end" markers, e.g. VSCode will inject special configuration into Bash to achieve exactly that – but it requires support from the terminal emulator and cooperation from every program that would show an input prompt, and neither Screen nor Minecraft will do that currently.)

On the other hand, your script might have an easier time because it only deals with a single program, which means it only needs to wait for a specific prompt to appear, not just any prompt in general. You could implement this by having a loop that would query Screen for the current buffer "contents" using -X hardcopy, and if the last line of that buffer is not the Minecraft prompt yet, sleep 1 second and repeat.

This is similar to how the expect program works: one can write an Expect script to automate various kinds of interactive input, but the core of such a script is always a set of expect "this" and expect "that", i.e. knowing up-front that some specific text is a "prompt" and waiting for that text.

[...]
expect "Password:" { send "$password\r" }
expect ">" { send "enable\r" }
expect "Password:" { send "$enablepwd\r" }
expect "#" { send "show run\r" }

What other Minecraft-management scripts do (such as this project, which recently switched from Screen to tmux) appears to be 1) blindly submit both "save-all" and "stop" at once, 2) wait for the server to process bot commands until it exits by itself. That is, instead of waiting for the command to complete, they wait for the result of that command.

Similarly, if you want to wait for the save to finish, you don't need to wait for the "save-all" command – you can instead use inotifywait to wait until the server has finished writing a specific file. This can be somewhat tricky to do right (normally you'd need to use "coproc" to start inotifywait before issuing the command so that you wouldn't miss the event), but as a save is likely to take a while, it's probably fine to just do it after.

echo "waiting..."
inotifywait -q -e close_write /path/to/game
echo "probably done!"

Some programs deliberately create a specific file last, so that other tools could wait for it to appear:

echo "waiting..."
until [ -e /path/to/marker_file ]; do sleep 1; done
echo "marker file showed up"

wait also (optionally) takes the PID of the process to wait for, and with $! you get the PID of the last command launched in the background. Modify the loop to store the PID of each spawned sub-process into an array, and then loop again waiting on each PID.

# run processes and store pids in array
pids=()
for i in $n_procs; do
    ./procs[${i}] &
    pids[${i}]=$!
done

# wait for all pids
for pid in ${pids[*]}; do
    wait $pid
done