Re: rln, a potential new core util

[David Laurence Emerson]

Jim Meyering wrote:
> 
> Enough people have requested this functionality over the years that
> I'm willing to add it now, maybe as ln --relative.  I have to admit
> that it'd be a useful complement to the functionality you get when
> using ln to create hard links: i.e., you don't have to worry about
> whether the working directory happens to be in the source or
> destination (or some other) directory.


Wow, that's really satisfying.  A few nights ago, I spent a long time 
composing a message to try to make a case for this, and then I couldn't 
send!  (I even went through the old fileutils archives and found six 
bug reports concerning this issue)  But it wasn't necessary after all.


Eric, Paul:  Thanks for your responses!


Jim:  I'd like to offer to help in any way that I can, although I'm not 
sure what form that could/should take, so do please let me know on the 
list or via private email if I can be of service.

(( Eric mentioned the necessity for snail mail paperwork in 
contributions, and I'd be happy to perform those necessary legal 
steps. ))


As a more discussion-oriented topic, I do have lots of ideas!  Of 
course, every programmer knows about 1% inspiration and 99% 
perspiration.  But some of these may be worth thinking about before 
setting down to code:

1. whether to use realpath (or an equivalent c library function) in all 
cases -- in particular, the case where a provided path that includes 
symlinks (but assumably not '..') results in a shorter or more 
desireable path.  ("desireable", hah!)

2. if the relative path must travel through root '/' then perhaps it 
should be made an absolute symlink (this shares ground with #1)

3. creating dead symlinks - disable/error, warn, prompt, enable, ignore?  
"disable/error" is what cp, mv, ln do for a non-existent source, but 
sometimes it would be nice to be prompted and to be able to create the 
link anyway.

(( Example of how to create a dead symlink: if realpath fails, use the 
realpath of the dirname of the target, and re-append the basename. If 
that fails, try to use the specified target without calling realpath. 
(this ties in again to #1) ))

4. awareness of network mounts... appropriate warnings/functionality???
 

The following ideas 5 & 6 probably have no place in this little 
discussion, and while it's unlikely that either of them will ever be 
implemented in the next decade, I thought I'd throw them out just for 
fun:

5. I don't know if any filesystems or kernels yet support it (or need 
to) but it would sometimes be nice to make symlinks relative to the 
root of the volume they are on, rather than pure relative or pure 
absolute.  The case I'm thinking of here is a volume which might be 
mounted at different locations but on which one would like to have 
absolute symlinks. Those two premises are, of course, incompatible 
without the (AFAIK) nonexistent symlinks relative to a volume.  This 
also crosses into the territory of mount flags.

6. symlinks relative to any user's home (this wouldn't work very well 
with the bash tab-completion I see, which expands a '~' tilde while 
tab-completing subdirectories or files)


~David.