2009/10/26 Glenn Tarbox, PhD <[email protected]>: > Beginning with Release 4.1.2, "sage -sh" was adjusted and now completely > strips the users environment as set in the various .*rc files. >
After I read this, I expected the following would happen: d-69-91-158-18:~ wstein$ export FOO="bar" d-69-91-158-18:~ wstein$ sage -sh Starting subshell with Sage environment variables set. Be sure to exit when you are done and do not do anything with other copies of Sage! Bypassing shell configuration files ... /Users/wstein sage subshell$ echo $FOO <nothing> However, it doesn't. In fact we get sage subshell$ echo $FOO bar So the new "sage -sh" does not remove *anything* set in your environment. I realize you didn't say it did. I just thought pointing out that I was confused initially might help other people. The change in "sage -sh" is that we used to have: 1. Set all sage environment variables. 2. Start a new shell, which can change everything in the environment in funny ways as it reads .bashrc (say). Now we have: 1. Set all sage environemnt variables. 2. Start a new shell, but don't read in the rc files, hence avoiding the environment getting changed back. The current version is a much better approximation to what happens when you run Sage itself and interact with the "sage:" prompt. Maybe a workaround would be to set the environment variables you need to set before you call "sage -sh"? > I'm assuming there were collisions between variables needed by sage and those > the user may be setting. However, this recent change seems extreme and makes > using the sage shell problematic (and somewhat annoying). > > I didn't see discussion or rationale for the change although I'm sure there > were good reasons. Without understanding exactly what the reason was, > however, makes it hard to know how to fix its side effects without breaking > whatever was being fixed. > > Of note: in bash, "PS1" was changed and now prints an extra line with the > $SAGE_ROOT value in addition to "sage subshell$". Thats a whole lotta > warning and, IMHO, overdone. This is easily fixed but brings up another > issue... is it now necessary to have a .sagerc and some strategy for > combining .bashrc and .sagerc so users can maintain consistency? > > I've previously reported what I consider inconsistencies in how sage sets > environment variables (#6610). I'm guessing that something broke so a "clean > room" approach to environment variables was taken. I would prefer that we > identify what needs to be set and be a bit more surgical WRT the sage > environment, at least for the sage shell. > > -glenn > > -- > Glenn H. Tarbox, PhD || 206-274-6919 || [email protected] - xmpp || ghtdak - > aim,jabber,IRC,yahoo > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
