Re: Feature Request: make sane symlinks on remote host.

[Kai Großjohann]

Steve Youngs <address@hidden> writes:

> |--==> "KG" == Kai Gro <address@hidden> writes:
>
>   KG> Steve Youngs <address@hidden> writes:
>   >>No, not at all.  I want...
>   >>
>   >>C-x C-f /address@hidden  (to get a dired listing of jrl's $HOME on 
> frumple)
>   >>M-x eshell
>   >>(make-symbolic-link "/path/to/file1" "/path/to/file2")
>   >>
>   >>Where "file1" and "file2" are _both_ on frumple.
>
>   KG> I see.  Now I understand your request.  But I don't like it :-)
>   KG> That would mean that the behavior of make-symbolic-link should depend
>   KG> on the variable default-directory.  No, this is not a good idea, I
>   KG> think.
>
>   KG> My suggestion is to interpret the source of the link (ie, LINKNAME,
>   KG> the second arg of make-symbolic-link) as a filename and to interpret
>   KG> the target of the link (ie, FILENAME, the first arg) as a string.
>
> Hey, whoa, that's not right, you've got the args the wrong way
> around... 
>
> ,----[ C-h f make-symbolic-link RET ]
> | `make-symbolic-link' is an interactive built-in function
> | (make-symbolic-link FILENAME LINKNAME &optional OK-IF-ALREADY-EXISTS)
> | 
> | Documentation:
> | Make a symbolic link to FILENAME, named LINKNAME.  Both args strings.

If it says "to FILENAME", then FILENAME must be the target of the
symlink.  Then LINKNAME must be the source.

I also tested this (on Emacs, but it's got the same documentation).

In the output of "ls -l", it prints something like "x -> y".  I use
"source" for x and "target" for y.  Of course, ln expects the
arguments the other way round.  Confusing...

* (make-symbolic-link "y" "x")

* ln -s y x

* ls -l
  ...
  ...  x -> y
  ...

Clear?

> | Signals a `file-already-exists' error if a file LINKNAME already exists
> | unless optional third argument OK-IF-ALREADY-EXISTS is non-nil.
> | A number as third arg means request confirmation if LINKNAME already exists.
> | This happens for interactive use with M-x.
> `----
>
>   KG> This way, you can say (make-symbolic-link "xyzzy"
>   KG> "/address@hidden/path/to/file") and it will always create a symlink
>   KG> on host, regardless of default-directory.
>
> So this should be...
>
> (make-symbolic-link "/address@hidden/path/to/file" "xyzzy")
>
> And default-directory _should_ play a part for at least two reasons:
>
>         1) Making a "relative" symbolic link.

Yes, it should be used for the source.  But in all other cases
"/tmp/foo" means a file on the local host; you want it to mean a file
on the remote host (if default-directory indicates that).  That seems
inconsistent.

>         2) A symlink should _never_ span different hosts.

Well, that's achieved by the target, not by the source.  I said that
the target should be interpreted as a string.

> IMO, what should happen in the above example is:
>
>         Tramp should connect to host if not already connected, setting
>         default-directory to '/address@hidden/path/to/' if not connected,
>         or './' if already connected.  Then test to see if the OS on
>         host supports symlinks (signalling the appropriate error if
>         not).  Do the normal 'make-symbolic-link' checks.  Strip off
>         any Tramp filename parts (the "/[...]" bit) and write the
>         symlink to disc.
>
> So that would make the correct syntax:
>
>         (make-symbolic-link "/[method/address@hidden/path/to/filename"
>                             "/path/to/symlink-name")
>
> And I'd be very happy with that. :-)

Oh, boy.  So there should be a new file /path/to/symlink-name on the
remote host, which is a symlink pointing to /path/to/filename on the
same host?

This is just weird.  Why don't you agree on putting the user/host
spec on the source rather than the target?

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)