On Nov 2, 6:33 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Fri, 02 Nov 2007 10:26:13 -0700, Justin C. Walker <[EMAIL PROTECTED]>
> wrote:
>
>
>
> >> Well, it also hits us on Linux, so I still think it should happen.
> >> malb's problem with firefox is just one example where that happened
> >> and he just fixed it in that special case, but not as clean and
> >> general as I would like.
>
> > This may be a hack, but it is an ingrained piece of behavior in Unix-
> > like systems. The issue is part and parcel of the "sage-env"
> > command's existence: you want to set up the "proper" environment in
> > which SAGE can function, and you do this by modifying the default
> > environment that the shell user normally sees. Therefore, if you
> > support the "!" functionality ("back to the default shell", in
> > essence), it seems to me that it behooves you to re-establish that
> > environment. Perhaps the right way to do this is to invoke a login
> > shell; I'm not sure though. An alternative would be to save/restore
> > those shell variables that SAGE sets (keeping in mind that if SAGE
> > sets one that isn't set, it ought to be unset).
>
> You are of course right.
>
> However, doing what we're discussing will also break
> some things too. E.g.,
>
> sage: !gap # or anything else included in sage
> boom since now the environments aren't right to
> run anything included in sage.
> sage: !lie
> boom
> sage: !mwrank
> boom
>
> So there are pros and cons to this suggested fix, which have to be
> carefully considered.
I think you misread one point I made: In case of !app we check if app
is in $SAGE_LOCAL/bin. In that case we don't do anything about
[DY]LD_LIBRARY_PATH and since it is the Sage version of app it should
work as always. Otherwise, i.e. app is not in $SAGE_LOCAL/bin, we are
calling something not shipped with Sage we use the old version of
[DY]LD_LIBRARY_PATH and avoid that the linker picks the wrong version
of certain libraries shipped with Sage.
>
> In the above case, if we also unset the changes we made to the PATH,
> then as long as the user do install_scripts(...), they will still
> be able to run gap (since that will call "sage -gap").
>
Cheers,
Michael
> William
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washingtonhttp://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
