To start off, I am using Windows 10 OS which is updated to its most recent updates, I also have Windows Subsytem Linux, (WSL), installed. On WSL, I am using the Ubuntu flavor, version 18.04, though this should not have any impact on what we are about to do. I struggled for a while attempting to find the correct answer as to why I kept getting an error after installing the Amazon Web Services Command Line Interface, or awscli on WSL. The error I kept getting was:
When I first started using this machine as my primary developer machine, I came from Linux, which has a lot of tools installed by default that Windows does not. For instance, Python comes already installed and ready to use on Linux. I use Python for a variety of things as well as the Python package installer, pip, so when I started with this computer I installed them right away. Not sure if this makes a difference but I at least want to be able to duplicate my environment in case anyone else is struggling with this. After installing python, both versions, 2.X.X and 3.X.X, as well as pip, since they are two different programs, I made sure to do it right and add it to my 'path' or Windows environment variables so it can be found. After that, I installed NPM and a variety of other tools including the awscli, WSL, GIT, and a few more. After installing all of this through PowerShell I realized after poking around, that I could have a Linux 'environment' called Windows Subsystem Linux. Since Linux is what I was used to and felt most comfortable with, I set out to install WSL. I wanted to use WSL for all of the things I had just loaded on my machine through PowerShell, so I had to duplicate a lot of my work. I made sure python 2.X.X and 3.X.X were installed on WSL. Since WSL is similar to a virtual machine or a distro all to itself - or a 'subsystem' - I was not sure if I could share these tools between the two environments. I have set up dual boot machines as well as virtual machines before and the explanations I read made it sound like it favored these kinds of an environment. I installed pip, Node, NPM, GIT, and all the other stuff I was using at the time onto WSL. One of the programs I use is the awscli. This allows you to interact with AWS or Amazon Web Services. I use their S3 storage as well as CloudFront, and Route 53, and a few other services. Being able to interact with these services via CLI is imperative for me.
After installing the awscli to Ubuntu WSL, I continued to get the same error as shown in the screenshot above. No matter what I did I seemed to continue getting this error. The last thing the error says is:
no such file or directory, so this is where I started. I traced the file location and confirmed there is actually such a file. Now I looked at the
bad interpreter: portion of the error message. My first thought is what does this even mean! 'Bad interpreter - no such file' - WHAT? The file is there. I can see it is there. That is when I set in to Google. I got a lot of Mac related results and a few that referred to Windows. Attempting to decipher those results was difficult since there seemed to be so many different 'solutions' depending on all the different environment setups. As you can see from the screenshot I use ZSH as my shell of choice instead of Bash so this was throwing me off some too.
I was able to recognize a few patterns all the 'solutions' had in common and just started trying different things. The Windows file system displays its path to a file differently than Linux. On Windows the path is represented this way:
C:\Users\Matth\AppData\Local and on Linux the path is represented
/usr/bin/python. This was throwing things off and it could not find the file. As you can see from the screenshot, I tried just about every different combination trying to get it to find the file. Finally, it dawned on me that I had installed python on Windows as well as on WSL. Once I figured out which python instance it was attempting to use by issuing the
which python command, it returned
/usr/bin/python. That told me it was using the WSL installed version of python.
At this point I was able to trace the path back to
C:\Users\Matth\AppData\Local\Programs\Python\Python37\Scripts\aws where the actual awscli file lived. The very first line, (see screenshot below), of the file starts with
#!/mnt/c/Users/Matth/AppData/Local/Programs/Python/Python37/Scripts/aws. Just looking at this path I could tell this was the problem. I use Hyper for a terminal and in that terminal I have it set up to default to the zsh shell installed on WSL. This is why in the path there is the first '/mnt' and the rest is self explanatory. Once in the file I just kept changing the URL until I could get it to work correctly. After I figured out it was attempting to use the python installation from WSL
/usr/bin/python I just used that for the URL on Line 1 of the awscli file and it worked immediately after that.
This was a really convoluted way to get it to work. I am confident there are other ways to do this. In fact, there are probably more 'economical' ways to do this. You may be able to use the python installation from the host OS, being Windows, but this seemed to be the easiest way to get this done so I can continue to work.