MESAHub/mesa

warning about use of shmesa on clusters

mjoyceGR opened this issue · 7 comments

mjoyceGR commented

raised by @nair-ashwathi

attempting to use shmesa to export a path on OzSTAR (Australian computing cluster, so remote use) had the quite undesirable effect of breaking all basic bash commands...nothing was usable except cd. I was able to fix the problem with force PATH reset

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

but this is not something we should expect a typical MESA user to know how to do to, and it's a very scary and difficult situation to have all terminal functionality break. The user could not use vim to open/look at .bashrc, which is the first thing any user would think to do if something like this happened.

Can we either add a large & loud warning about this in the shmesa docs or avoid encouraging people who are not familiar with shell scripting (like summer school participants) to use it? bash utilities can be a bit dangerous for beginners, especially coupled with running jobs remotely, when even more advanced users may not have much knowledge about how the clusters are configured

earlbellinger commented

Thanks for the bug report. What does using shmesa to export a path mean?

mjoyceGR commented

Sorry for lack of clarity-- what happened is this:

student exported the path to shmesa in .bashrc
sourced their .bashrc
restarted the terminal

then use of all terminal commands except cd were lost

earlbellinger commented

Thanks! That's a bit puzzling -- we should get to the bottom of it. What operating system and bash version is used on the machine where this bug happens?

warrickball commented

Did the student perhaps do something like

export PATH=$MESA_DIR/scripts/shmesa

rather than

export PATH=$PATH:$MESA_DIR/scripts/shmesa

?

  • 👍2
evbauer commented

That was my thought too. In principle, we aren't recommending doing anything different to the path than the SDK does in its initialization script. But I suppose the SDK initialization handles the path manipulation under the hood, while we're having a user edit the path themself, which carries a bit more risk of error?

nair-ashwathi commented
earlbellinger commented

Good catch. Yes, that will definitely cause it: bash looks at $PATH to find programs like ls and vim, usually in /bin/bash. So overwriting it means that shmesa is the only thing bash knows how to find. Be sure to only append it, via PATH=$PATH:$MESA_DIR/scripts/shmesa as in the instructions.