I ran into the same issue that you are facing and this is how I got it fixed:

1. Just want to be careful, you need to exist the Terminal and open a fresh one to start. This way, you are not under any devtoolset's bash.
2. Go to /opt/rh folder, run command ls -la to see if you have any devtoolset-* folder there. Let's say you have devtoolset-8, proceed step 2.
3. Go to /etc/scl/prefixes folder, if you don't see devtoolset-8 file, you can create a new one as devtoolset-8, and type 1 line: /opt/rh, then save and quit that file.
4. Once you are done, you can call: scl enable devtoolset-8 -- bash w/o any error. Good luck

It is because of your settings in .bashrc and/or .bash_profile. scl appends its path to gcc7 before starting your new bash shell, but the path to gcc is default to the old gcc4 again because your .bashrc appends /usr/bin to the path when starting the new bash, and it supersedes the scl settings. The solution is to use the "enable" script directly. That way no further path settings annoy you.

An alternative of source /opt/rh/devtoolset-4/enable is

source scl_source enable devtoolset-4

The above shell script scl_source is more elegant than using a hard coded path (may be different on another machine). However scl_source does less because /opt/rh/devtoolset-4/enable uses scl_source and other stuff.

To use scl_source you may have to upgrade package scl-utils

yum update scl-utils  # old scl-utils versions miss scl_source

Quick copy-paste

echo 'source scl_source enable devtoolset-4' >> ~/.bashrc
    # Do not forget to change the version ↑

Source code for curious people

An example of scl_source source code:
https://gist.github.com/bkabrda/6435016

The scl_source installed on my Red Hat 7.1

#!/bin/bash

_scl_source_help="Usage: source scl_source <action> [<collection> ...]

Don't use this script outside of SCL scriptlets!

Options:
    -h, --help    display this help and exit"

if [ $# -eq 0 -o $1 = "-h" -o $1 = "--help" ]; then
    echo "$_scl_source_help"
    return 0
fi


if [ -z "$_recursion" ]; then
    _recursion="false"
fi
if [ -z "$_scl_scriptlet_name" ]; then
    # The only allowed action in the case of recursion is the same
    # as was the original
    _scl_scriptlet_name=$1
fi
shift 1

if [ -z "$_scl_dir" ]; then
    # No need to re-define the directory twice
    _scl_dir=/etc/scl/conf
    if [ ! -e $_scl_dir ]; then
        _scl_dir=/etc/scl/prefixes
    fi
fi

for arg in "$@"; do
    _scl_prefix_file=$_scl_dir/$arg
    _scl_prefix=`cat $_scl_prefix_file 2> /dev/null`
    if [ $? -ne 0 ]; then
        echo "Can't read $_scl_prefix_file, $arg is probably not installed."
        return 1
    fi

    # First check if the collection is already in the list
    # of collections to be enabled
    for scl in ${_scls[@]}; do
        if [ scl ]; then
            continue 2
        fi
    done

    # Now check if the collection isn't already enabled
    /usr/bin/scl_enabled $arg > /dev/null 2> /dev/null
    if [ $? -ne 0 ]; then
        _scls+=($arg)
        _scl_prefixes+=($_scl_prefix)
    fi;
done

if [ $_recursion == "false" ]; then
    _i=0
    _recursion="true"
    while [ {#_scls[@]} ]; do
        _scl_scriptlet_path="${_scl_prefixes[$_i]}/${_scls[$_i]}/${_scl_scriptlet_name}"
        source "$_scl_scriptlet_path"
        if [ $? -ne 0 ]; then
            echo "Can't source $_scl_scriptlet_name, skipping."
        else
            export X_SCLS="${_scls[$_i]} $X_SCLS"
        fi;
        _i=_i+1))
    done
    _scls=()
    _scl_prefixes=()
    _scl_scriptlet_name=""
    _recursion="false"
fi

to get the script to act as you want it to, you need the scl command to modify the current bash session rather than spawn a new one.

you can do it this way

#!/usr/bin/env bash

# switch to GCC9 environment for the duration of the script
source scl_source enable devtoolset-9

gcc --version

The parsing of arguments in the she-bang command is not really defined. From man execve:

The semantics of the optional-arg argument of an interpreter script vary across implementations. On Linux, the entire string following the interpreter name is passed as a single argument to the interpreter, and this string can include white space. However, behavior differs on some other systems. Some systems use the first white space to terminate optional-arg. On some systems, an interpreter script can have multiple arguments, and white spaces in optional-arg are used to delimit the arguments.

No matter what, argument splitting based on quote sis not supported. So when you write:

#!/usr/bin/scl enable python27 "ls /tmp"

It's very possible that what gets invoked is (using bash notation):

'/usr/bin/scl' 'enable' 'python27' '"ls' '/tmp"'

This is probably why it tries to open the "ls file at /etc/scl/prefixes/"ls

But it is just as likely that the shebang evaluates to:

'/usr/bin/scl' 'enable python27 "ls /tmp"'

And that would fail since it wont be able to find a command named enable python27 "ls /tmp" for scl to execute.

There's a few workarounds you can use.

You can call your script via scl:

$ cat myscript
#!/bin/bash
echo hello

$ scl enable python27 ./myscript
hello

You can also use the heredoc notation, but it might lead to subtle issues. I personally avoid this:

$ cat ./myscript
#!/bin/bash
scl enable python27 -- <<EOF
echo hi
echo \$X_SCLS
EOF

$ bash -x myscript 
+ scl enable python27 --
hi
python27

You can see one of the gotcha's already: I had to write \$X_SCLS to access the environment variable instead of just $X_SCL.

Edit: Another option is two have two scripts. One that has the actual code, and the second that simply does scl enable python27 $FIRST_SCRIPT. Then you wont have to remember to enter scl ... manually.