RESOLVED: Why would a WordPress Workspace suddenly be Read-Only when others are fine?



I have Roots/Sage 8.5.1 configured on a theme in a WordPress Workspace. I’ve been running Gulp commands every which way for weeks. It’s been working great. Suddenly, I open the space and neither gulp or bower are installed:

bash: gulp: command not found
bash: bower: command not found

The file-system for this workspace is read-only. When I clone it, that’s read-only as well. All of my other Workspaces are working fine, I’m package managing all over the place.

I have Cloud9 IDE Pro $19.00 Individual Plan / not due until June.

My processes are almost all 0% and I’ve restarted the workspace from stats menu twice.

What would cause this? What diagnostic info can I provide here for insight? How do I prevent this?


##UPDATE: Resolved below.


maybe you were using another version of nvm before?
try running nvm ls to see istalled versions, then nvm use ,.. for each version, unril you find the version with gulp.


thanks harutyun. unfortunately, the entire workspace is in read-only mode.

nvm ls (or any other commands outside of default ubuntu setup) gets:
bash: nvm: command not found

It’s as if that workspace has been shut down for exceeding RAM quota, but I’ve received no warning and all my other very similar workspaces are working fine. I don’t get it. No word from support yet. After 2 hours of trying to solve, I spent another 2 hours rebuilding the deployment setup with a new workspace…

If I did something to trigger it, I’ll gladly accept responsibility! but it appears to be “random”, or at least the reason hasn’t been communicated in any way. We’ll see :slight_smile:


maybe you have changed bashrc, and nvm is not loaded anymore?
What is the url of your workspace?


#YES! RESOLVED! I :heart:

Once again, Cloud9 comes through with great support - and of course the bug was caused by something I did without realizing it:

On my home machine, I’m used to using a bunch of aliases I’ve set up in ~/.bash_profile like typing gits instead of git status and so on.

Well apparently I’m a noob douche and didn’t realize that adding a .bash_profile file disables the loading of .profile, and therefore the loading of nvm. In order to keep using the custom .bash_profile with nvm @harutyun hooked up with a hack that worked flawlessly. I just add this to .bash_profile and voila!

export NVM_DIR="/home/ubuntu/.nvm" [ "$BASH_VERSION" ] && npm() { if [ "$*" == "config get prefix" ]; then which node | sed "s/bin\/node//"; else $(which npm) "$@"; fi } # hack: avoid slow npm sanity check in nvm [ -s "$NVM_DIR/" ] && . "$NVM_DIR/" # This loads nvm unset npm # end hack

Admittedly, I’m a command line amateur and didn’t realize I was causing a bashrc collision. I publicly apologize for being frustrated with C9 for a bug that I caused :slight_smile: Onward and upward - thanks again harutyun & C9 support!