[Toybox] Questions about realpath -s

[Rob Landley]

You asked about:

> On 7/23/21 4:26 PM, enh wrote:
>>   realpath (-s (--no-symlinks), --relative-to)
> 

Do you want the exact behavior of the gnu one, or do you want consistent
behavior? Because:

  $ ls -l Xilinx
  lrwxrwxrwx 1 landley landley 10 Dec 13  2019 Xilinx -> old/Xilinx
  $ realpath Xilinx/..
  /home/landley/old
  $ realpath -s Xilinx/..
  /home/landley
  $ cd Xilinx
  $ realpath ..
  /home/landley/old
  $ realpath -s ..
  /home/landley/old

Is inconsistent in how it treats the path supplied on the command line (may
contain symblinks) and the path to the current directory (readlink -f).

I _think_ realpath -s should use $PWD as the "path to this point" instead of
getcwd(), because we may have traversed symlinks to get here and realpath -s
seems to be trying to do the "cd .." thing where .. unravels $PWD instead of
resolving ".." to navigate up the actual filesystem hierarchy...

But that's not what the gnu one is doing? The gnu one is doing one thing when
the .. eats a directory we just supplied, and a different thing when .. eats a
directory we're in, even WHEN the directory we're in is a symlink and we can
tell that because the shell exports $PWD. In fact:

  $ env -i bash -c env
  PWD=/home/landley/old/Xilinx
  SHLVL=0
  _=/usr/bin/env

PWD is one of three variables exported by default into an empty environment.
(And I can always fall back to getcwd() if $PWD isn't set, or if I'm feeling
fancy if it doesn't stat equal to ".")

Also:

  $ realpath -s doesnotexist/..
  realpath: doesnotexist/..: No such file or directory

(See also "realpath -s really can't cope when cwd has been deleted".)

It would be nice if there was a specification for this...

Rob

P.S. Busybox realpath doesn't have -s, so I haven't got a second opinion here.

P.P.S. This:

  $ realpath -s Xilinx/14.7/../..
  /home/landley
  $ realpath --relative-to Xilinx -s Xilinx/14.7/../..
  ..

Makes me sad, but I suppose what it asked for is "the relative path you feed to
cd to get there"...