<div dir="ltr"><div>i've not used either option personally, so i have no opinion either, and would default to "whichever's easier until proven otherwise". (and there is no realpath(1) on macOS, so no second opinion from that direction either.)</div><div><br></div>the specific `realpath --relative-to` request i've seen was specifically for the kernel's CONFIG_IKHEADERS option, though there are a handful of uses in the AOSP tree too.<div><br></div><div>uses of `realpath --no-symlinks` just seems to be a few "random" use cases. i think they're just to make the path more readable for humans!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 25, 2021 at 4:05 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You asked about:<br>
<br>
> On 7/23/21 4:26 PM, enh wrote:<br>
>>   realpath (-s (--no-symlinks), --relative-to)<br>
> <br>
<br>
Do you want the exact behavior of the gnu one, or do you want consistent<br>
behavior? Because:<br>
<br>
  $ ls -l Xilinx<br>
  lrwxrwxrwx 1 landley landley 10 Dec 13  2019 Xilinx -> old/Xilinx<br>
  $ realpath Xilinx/..<br>
  /home/landley/old<br>
  $ realpath -s Xilinx/..<br>
  /home/landley<br>
  $ cd Xilinx<br>
  $ realpath ..<br>
  /home/landley/old<br>
  $ realpath -s ..<br>
  /home/landley/old<br>
<br>
Is inconsistent in how it treats the path supplied on the command line (may<br>
contain symblinks) and the path to the current directory (readlink -f).<br>
<br>
I _think_ realpath -s should use $PWD as the "path to this point" instead of<br>
getcwd(), because we may have traversed symlinks to get here and realpath -s<br>
seems to be trying to do the "cd .." thing where .. unravels $PWD instead of<br>
resolving ".." to navigate up the actual filesystem hierarchy...<br>
<br>
But that's not what the gnu one is doing? The gnu one is doing one thing when<br>
the .. eats a directory we just supplied, and a different thing when .. eats a<br>
directory we're in, even WHEN the directory we're in is a symlink and we can<br>
tell that because the shell exports $PWD. In fact:<br>
<br>
  $ env -i bash -c env<br>
  PWD=/home/landley/old/Xilinx<br>
  SHLVL=0<br>
  _=/usr/bin/env<br>
<br>
PWD is one of three variables exported by default into an empty environment.<br>
(And I can always fall back to getcwd() if $PWD isn't set, or if I'm feeling<br>
fancy if it doesn't stat equal to ".")<br>
<br>
Also:<br>
<br>
  $ realpath -s doesnotexist/..<br>
  realpath: doesnotexist/..: No such file or directory<br>
<br>
(See also "realpath -s really can't cope when cwd has been deleted".)<br>
<br>
It would be nice if there was a specification for this...<br>
<br>
Rob<br>
<br>
P.S. Busybox realpath doesn't have -s, so I haven't got a second opinion here.<br>
<br>
P.P.S. This:<br>
<br>
  $ realpath -s Xilinx/14.7/../..<br>
  /home/landley<br>
  $ realpath --relative-to Xilinx -s Xilinx/14.7/../..<br>
  ..<br>
<br>
Makes me sad, but I suppose what it asked for is "the relative path you feed to<br>
cd to get there"...<br>
</blockquote></div>