#5852: [with patch, positive review] the detection of SAGE_ROOT in
$SAGE_ROOT/sage
script should expand symlinks recursively (fix this on systems that support
readlink -f)
----------------------+-----------------------------------------------------
Reporter: tornaria | Owner: tornaria
Type: defect | Status: closed
Priority: major | Milestone: sage-4.0
Component: misc | Resolution: fixed
Keywords: | Reviewer:
Author: | Merged:
----------------------+-----------------------------------------------------
Comment(by tornaria):
Replying to [comment:8 was]:
> Question. Does
> {{{
> readlink -n sage
> }}}
> work on any platform?!
Yes it does: it reads the content of a symbolic link. It succeeds if and
only if the argument is actually a symbolic link, e.g.
{{{
~/sandbox$ ls -l
total 0
~/sandbox$ mkdir sage1
~/sandbox$ readlink sage1 ; echo $? ## fails b/c sage1 is not a symlink
1
~/sandbox$ ln -s sage1 sage2
~/sandbox$ readlink sage2 ; echo $? ## ok b/c sage2 is actually a symlink
sage1
0
}}}
The option {{{-n}}} means to not print a trainling newline character; I
don't think it really make a difference due to bash usual escaping rules.
> It gives an error on *both* OS X and Linux. Why is it even there?!
It was there before the patch in this ticket, so that if {{{$0}}} (the
path to the script one is running) is actually a symlink to the real path
of the sage script, the detection of {{{SAGE_ROOT}}} works. On systems
that support {{{-f}}}, that is a more complete solution, but the fallback
was left for the benefit of systems where {{{readlink -f}}} does not work
(e.g. OS X).
Following my example above, here's an example where {{{-f}}} is needed:
{{{
~/sandbox$ ln -s sage2 sage3
torna...@bip:~/sandbox$ readlink -n sage3
sage2torna...@bip:~/sandbox$ readlink sage3
sage2
torna...@bip:~/sandbox$ readlink -f sage3
/home/tornaria/sandbox/sage1
}}}
The other major case is when there are symlinks in some of the components
of the path, those get canonicalized by {{{readlink -f}}}, but not by
plain {{{readlink}}} (this leads to failures as shown in the description).
> By the way, I've had reports of major failures caused by using
{{{readlink -nf}}} by one user who has a symlink + nfs mount setup. Their
problems are solved by deleting the {{{readlink -nf}}} line. Why don't
we use realpath first and only if that doesn't work use something else?
It seems like realpath is the right choice, since it's supposed to "
converts each filename argument to an absolute pathname, which has no
components that are symbolic links or the special
> . or .. directory entries... Please note that mostly the same
functionality is provided by the â-fâ option."
Can you give a pointer to those? Not using {{{readlink -f}}} leads to
major failures in testing, as described in the description of the ticket.
Do you actually know that in those cases {{{realpath}}} works? It seems to
me that both are implemented using {{{realpath(3)}}}, so they should be
the same unless I'm missing something.
> There is no realpath on OS X, but that is ok since readlink doesn't work
ever on OS X anyways, so no loss.
There is no {{{realpath}}} in most systems I have access to (other than
sage.math). In fact, {{{readlink}}} is pretty much standard (possibly
POSIX), although {{{-f}}} option is not (a GNUism?). For GNU systems (e.g.
linux), it comes bundled in coreutils, which means it will be available
everywhere. OTOH, {{{realpath}}} comes in ''optional'' package
{{{realpath}}}. Do you know of a system where {{{readlink -f}}} doesn't
work but {{{realpath(1)}}} is available?
OTOH, realpath(3) seems to be a POSIX standard, and it seems to be
available on OS X:
{{{
$ nm /usr/lib/libc.dylib | grep realpath
/usr/lib/libc.dylib(realpath.So):
9003f1f0 T _realpath
}}}
so an alternative would be to compile our own {{{realpath}}} binary and
somehow use it from the startup script. But we need a path to SAGE_ROOT so
we can find SAGE_ROOT/local/bin/realpath... auch... (doesn't need to be
canonical, though.... so we could use readlink a few times to get a path
to the actual sage script, and then run {{{realpath}}} from there).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5852#comment:9>
Sage <http://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
-~----------~----~----~----~------~----~------~--~---
