There was a much easier way to achieve this:

Add the Alonid's repo to /etc/yum.repos.d/epel.repo (assuming you have epel repo installed)

echo "[alonid-llvm-3.9.0]
name=Copr repo for llvm-3.9.0 owned by alonid
baseurl=https://copr-be.cloud.fedoraproject.org/results/alonid/llvm-
3.9.0/epel-7-$basearch/
type=rpm-md
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://copr-be.cloud.fedoraproject.org/results/alonid/llvm-
3.9.0/pubkey.gpg
repo_gpgcheck=0
enabled=1
enabled_metadata=1" >> /etc/yum.repos.d/epel.repo

Then just sudo yum install clang-3.9.0

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.

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.

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