MESAHub / mesa

Modules for Experiments in Stellar Astrophysics
http://mesastar.org
GNU Lesser General Public License v2.1
145 stars 39 forks source link

warning about use of shmesa on clusters #660

Closed mjoyceGR closed 5 months ago

mjoyceGR commented 5 months ago

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 5 months ago

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

mjoyceGR commented 5 months ago

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 5 months ago

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 5 months ago

Did the student perhaps do something like

export PATH=$MESA_DIR/scripts/shmesa

rather than

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

?

evbauer commented 5 months ago

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 5 months ago

Hi Warrick,

Yes I did PATH = $MESA_DIR/scripts/shmesa which might have caused it?

Thanks, Ashwathi.

On Fri, Jun 21, 2024, 1:14 a.m. Warrick Ball @.***> wrote:

Did the student perhaps do something like

export PATH=$MESA_DIR/scripts/shmesa

rather than

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

?

— Reply to this email directly, view it on GitHub https://github.com/MESAHub/mesa/issues/660#issuecomment-2180952003, or unsubscribe https://github.com/notifications/unsubscribe-auth/APR2X5ILKNXDPP3UU3UZLN3ZILWUBAVCNFSM6AAAAABJRKYYJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBQHE2TEMBQGM . You are receiving this because you were mentioned.Message ID: @.***>

earlbellinger commented 5 months ago

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.