Day 23: Learning Shell Scripting Paid Off

There are some days that make you feel like all that hard work was worth it. Today was one of those days. I’ve always used package managers like npm and composer or pip but whenever something went wrong I had no idea what to do besides look for a solution to copy and paste. Today was different. I was able to systematically read through and follow the lines of code written in the shell scripts to find the source of my problem. It took me a long time to do it but that first experience is what matters.

TLDR;

Okay, so here are the highlights of what I did:

  • I was able to fix the issue in my system that made it so that I could not effectively run the sass compiler or any other npm package successfully from Git Bash. Currently, I have the tsc 'typescript compiler' , gulp , and sass all running successfully from Git Bash!!! I’m not using all of them at once, they just happen to be on my system from separate projects so I tested them all out.

How Learning Shell Scripting Paid Off

So I took the slow and steady approach that I love and started to go through the sass shell script line by line. My goal was to try and recognize as much as I could and find the step-by-step process that was occurring from the script’s code. It was frustrating and I had to look up a bunch of built-in CLI programs that I have yet to use. Although, it was difficult, the feeling that I have now knowing that I solved the problem and understood the solution is incomparable.

The text immediately below is from yesterday… Just goes to show that if you stick with something you can figure it out eventually.

Frustration and My Plan to Fix It

I honestly don’t have much to say today except that I am frustrated. All that I can say is that I need to review some key concepts from terminals and computer environments. I learned a bit but I know my understanding of globals Paths and Environment variables is still a bit fuzzy. I had opened two Wikipedia pages on the topics about a week ago but never got around to reading them. I guess now is the time and I can start tomorrow.

Ultimately, being stuck means that this is an opportunity for me to learn and better understand what the problem is and why I’m having this problem. This is not the “Stack overflow magic solution time”. It may be slow but I truly believe in taking a step by step approach and moving with competence rather than rushing. Anyways I’m still frustrated lol.

The Problem and My Solution

I was trying to run npm packages from Git Bash but I kept getting like this:

C:\Users\{username}\AppData\Roaming\npm/node_modules/node/bin/node: line 1: This: command not found

I was very super confused as to why this was happening because all the npm packages would run perfectly fine from the Windows CMD. So I went through the sass script file that was run when calling sass --version or anything else and here’s what I saw:

#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")

case `uname` in
    *CYGWIN*|*MINGW*|*MSYS*) basedir=`cygpath -w "$basedir"`;;
esac

if [ -x "$basedir/node" ]; then
  "$basedir/node"  "$basedir/node_modules/sass/sass.js" "$@"
  ret=$?
else 
  node  "$basedir/node_modules/sass/sass.js" "$@"
  ret=$?
fi
exit $ret

Initially I thought that the problem was in this file but I slowly and painfully learned that the issue was in the node script file that was called in the if statement. The node program that was called was not the one loaded as a program file on windows but rather the one that lives on npm. Tbh, I’m still fuzzy on the exact differences but I believe the npm version of node can be modified or pulled back so that we can run a different versions of node in different projects.

Anyways… the shell script the $basedir/node called was this:

#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")

case `uname` in
    *CYGWIN*|*MINGW*|*MSYS*) basedir=`cygpath -w "$basedir"`;;
esac

# I switched node -> node.exe since node doesn't run anything for us and is left blank intentionally. - j8ahmed
# "$basedir/node_modules/node/bin/node"   "$@"
# End of my edits - j8ahmed
# Reference for edits: https://github.com/nodejs/node/issues/29287
"$basedir/node_modules/node/bin/node.exe"   "$@"
exit $?

This is where things got interesting. I had mistakenly come to the conclusion that both the sass script and the node script were converting the file paths to the Windows format and that is why things weren’t working. I tried to add my own special case for MINGW64_NT to stop it from converting the path format. That did not help…

Based on the discussions that I found, I learned that this problem was likely the result of old code that was not cleaned up on updates. There were multiple solutions that worked but I chose the solution that required writing inside the node script file as you can see above. The solution was literally just adding 4 characters to one line of code. Kind of crazy, but hey, that’s programming for you.

# Old code that caused all packages not to run
"$basedir/node_modules/node/bin/node"   "$@"

# New code that works perfectly... for now anyways
"$basedir/node_modules/node/bin/node.exe"   "$@"

Anyways, this was an amazing learning exercise for me and although I had planned to learn other things this weekend, this was a phenomenal experience and I’m grateful that I got to have it. It has made me feel even more confident in choosing to learn more about the terminal, and shell scripting and all these less popular topics in coding.

Conclusion

That’s all for today. If you are interested in the MIT course you can check out the video lecture I’m currently going through. The lecture is helpful but isn’t sufficient by itself. Anyways, until next time PEACE!