William Stein wrote: > 2009/10/26 Glenn Tarbox, PhD <gl...@tarbox.org>: >> 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. >
Plus it indicates $subshell by default! So you can't forget to exit. This has bitten me more than once! Jaap > 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 || gl...@tarbox.org - xmpp || ghtdak - >> aim,jabber,IRC,yahoo >> >> > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
