#10967: R breaks if SAGE_LOCAL undefined
--------------------------------------------------------------+-------------
   Reporter:  ahd                                             |          Owner: 
 tbd                                       
       Type:  defect                                          |         Status: 
 new                                       
   Priority:  minor                                           |      Milestone: 
 sage-duplicate/invalid/wontfix            
  Component:  packages                                        |       Keywords: 
 R script SAGE_LOCAL R.sh.in spkg local/bin
Work_issues:  Review as soon as #9668 is ready (new R spkg).  |       Upstream: 
 N/A                                       
   Reviewer:                                                  |         Author: 
                                           
     Merged:                                                  |   Dependencies: 
 #9668                                     
--------------------------------------------------------------+-------------
Changes (by leif):

  * keywords:  R => R script SAGE_LOCAL R.sh.in spkg local/bin
  * dependencies:  => #9668
  * work_issues:  => Review as soon as #9668 is ready (new R spkg).
  * milestone:  sage-4.7.2 => sage-duplicate/invalid/wontfix


Comment:

 Replying to [comment:17 leif]:
 > ... although I think I wasn't expecting someone to run Sage's R from
 "outside"...

 ''Thinking a bit more about this:'' ;-)

 In general, ''none'' of the "stand-alone" programs like R, the PARI/GP
 interpreter, Maxima etc. as shipped with and installed by Sage (and almost
 none of the scripts) in `$SAGE_ROOT/local/bin/` are intended to be called
 directly ''from outside the Sage environment'', hence there's also no
 point in putting this directory into one's `PATH` (i.e., one shouldn't).

 Instead, one can do any of the following:

  * Start a Sage subshell (`sage --sh`), which then has the full Sage
 environment set up, and also `$SAGE_ROOT/local/bin/` in its `PATH`, such
 that running e.g. (Sage's) R by typing simply `R` at the command prompt
 works.

  * Run (e.g.) `sage --R` from any shell to start Sage's R (assuming an
 instance of `$SAGE_ROOT/sage` is found along one's "global" `PATH`;
 otherwise `/path/to/SAGE_ROOT/sage --R` or `cd $SAGE_ROOT && ./sage --R`).

  * Use the `install_scripts()` function from the `sage:` prompt to create
 light-weight "shortcut" scripts for all "stand-alone" components
 (programs) installed by Sage, or one can run it by for example
 {{{
 #!sh
 $ ./sage -c "install_scripts('$HOME/bin')"
 }}}
    or
 {{{
 #!sh
 $ sudo ./sage -c "install_scripts('/usr/local/bin')" # needs root
 privileges
 }}}
   Afterwards, provided that both an instance of `$SAGE_ROOT/sage` is found
 along and the directory passed to `install_scripts()` is contained in
 `PATH`, one can start (e.g.) Sage's R again by simply typing `R` from any
 shell, i.e., ''also from "outside the Sage environment"''. [[BR]]

  ''Note: `install_scripts()` currently has a flaw in that the created
 shortcuts do not support spaces in arguments passed to them; this has been
 fixed at #11602, which has been merged into Sage 4.7.2.alpha2.''

 [[BR]]

 Nonetheless, I agree that we should at least add a sanity check to e.g.
 `$SAGE_ROOT/local/bin/R`, such that it exits with an appropriate error
 message in case `SAGE_LOCAL` isn't defined (like many scripts already do).
 I guess such a test is currently missing just because nobody thought of
 someone trying to call this (and some other scripts) directly, since
 having them in the `PATH` without a properly set up environment was never
 intended.

 I can (and will perhaps) also make ''some'' scripts automatically execute
 themselves in a Sage environment, since this (to me) seems convenient for
 e.g. `devel/sage/spkg-dist`, but most probably not scripts like `R` in
 `$SAGE_ROOT/local/bin/`, because of the alternatives already present as
 given above.

 ----

 I'll address the specific issue with the R script(s) at #9668 (''not''
 #9968 ;-) ), so I've added that ticket as a dependency.

 After I've fixed this there (by simply adding a sanity check), this ticket
 should IMHO be closed as duplicate (not to say ''"invalid/won't fix"'').

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10967#comment:18>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to