MacOS – terminal starts with `no such file or directory` message

Check the contents of your ~/.bash_profile, or ~/.bashrc, for anything regarding this.

You can try renaming all three files to something else, then relaunch Terminal. If the problem goes away, put each file back one by one and test each time to find which file contains the 'bad' line.

Prior to OS X El Capitan 10.11, the code in /etc/bashrc arranges to send an escape sequence at each prompt to tell Terminal what the current working directory is, but this code only percent-encodes spaces, which means that it doesn't work with characters that are not valid URL characters, which includes any non-ASCII characters like “Ü”:

update_terminal_cwd() {
    # Identify the directory using a "file:" scheme URL,
    # including the host name to disambiguate local vs.
    # remote connections. Percent-escape spaces.
    local SEARCH=' '
    local REPLACE='%20'
    local PWD_URL="file://$HOSTNAME${PWD//$SEARCH/$REPLACE}"
    printf '\e]7;%s\a' "$PWD_URL"
}

On 10.11 and later, the code has been moved to /etc/bashrc_Apple_Terminal and has been updated to percent-encode all characters that require it, so it can now work with characters like “Ü” (your example case works for me on 10.11.1):

update_terminal_cwd() {
    # Identify the directory using a "file:" scheme URL, including
    # the host name to disambiguate local vs. remote paths.

    # Percent-encode the pathname.
    local url_path=''
    {
        # Use LC_CTYPE=C to process text byte-by-byte. Ensure that
        # LC_ALL isn't set, so it doesn't interfere.
        local i ch hexch LC_CTYPE=C LC_ALL=
        for ((i = 0; i < ${#PWD}; ++i)); do
            ch="${PWD:i:1}"
            if [[ "$ch" =~ [/._~A-Za-z0-9-] ]]; then
                url_path+="$ch"
            else
                printf -v hexch "%02X" "'$ch"
                # printf treats values greater than 127 as
                # negative and pads with "FF", so truncate.
                url_path+="%${hexch: -2:2}"
            fi
        done
    }

    printf '\\e]7;%s\\a' "file://$HOSTNAME$url_path"
}

[iTerm 2 apparently reads the working directory from the shell process state. This has the advantage that it works without any shell setup; however, it isn't guaranteed to be correct (there's no reason a shell's current working directory has to actually match the cwd it uses when executing a command, at any given moment), it doesn't work through indirect connections like ssh or shells running within editors or screen multiplexers, and it can't read the directory from processes owned by other users—for example, if you use sudo -s to create a root shell, it can't read the working directory from the root shell process. Furthermore, the program state only includes a file descriptor for the open directory, not the path that the shell is using for $PWD, so you won't actually get the path you used to navigate to the current directory in some cases—e.g., if you traversed through a symbolic link.]