Re: kern/58306: procfs does not remove dot segments from executablepaths

[まちゃラテ <matyalatte%gmail.com@localhost>]

The following reply was made to PR kern/58306; it has been noted by GNATS.

From: =?UTF-8?B?44G+44Gh44KD44Op44OG?= <matyalatte%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: riastradh%netbsd.org@localhost
Subject: Re: kern/58306: procfs does not remove dot segments from executablepaths
Date: Wed, 5 Jun 2024 21:26:31 +0900

 --000000000000c70481061a23ade4
 Content-Type: text/plain; charset="UTF-8"
 
 Thanks for the reply.
 
 > Why should the path be normalized like this?
 Because other unix variants will do it.
 I've tested on Ubuntu 20.04, FreeBSD 14.0 (with enabled procfs), and
 OpenIndiana 2023.10.
 They returned resolved exe paths from readlink() even if I used symlinks.
 like this
 ```
 $ cd /home/myname/myrepo
 $ ln -s mylink ./build/myexe
 $ ./build/../mylink
 exe path: /home/myname/myrepo/build/myexe
 ```
 
 > The Linux man page doesn't say anything about normalization
 I think "the actual pathname" in the doc means the normalized path. (I'm
 not sure tho.)
 
 Well, I just thought it could be a bug because it worked in a different way
 from other unix variants.
 Idk if there is a rational reason for procfs to normalize paths, or if it's
 just a matter of preference.
 It's ok to close this PR if you say it's an expected behavior.
 
 --000000000000c70481061a23ade4
 Content-Type: text/html; charset="UTF-8"
 Content-Transfer-Encoding: quoted-printable
 
 <div dir=3D"ltr"><div>Thanks for the reply.</div><div><br></div>&gt;=C2=A0<=
 span style=3D"color:rgb(0,0,0)">Why should the path be normalized like this=
 ?</span><div><span style=3D"color:rgb(0,0,0)">Because other unix variants w=
 ill do it.</span></div><div><span style=3D"color:rgb(0,0,0)">I&#39;ve teste=
 d on Ubuntu 20.04, FreeBSD 14.0 (with enabled procfs), and OpenIndiana 2023=
 .10.</span></div><div><span style=3D"color:rgb(0,0,0)">They returned resolv=
 ed exe paths from readlink() even if I used symlinks.</span></div><div><spa=
 n style=3D"color:rgb(0,0,0)">like this</span></div><div><span style=3D"colo=
 r:rgb(0,0,0)">```</span></div><div><span style=3D"color:rgb(0,0,0)">$ cd=C2=
 =A0</span><span style=3D"color:rgb(0,0,0)">/home/myname/myrepo</span></div>=
 <div><span style=3D"color:rgb(0,0,0)">$ ln -s mylink ./build/myexe</span></=
 div><div><span style=3D"color:rgb(0,0,0)">$ ./build/../mylink</span></div><=
 div><font color=3D"#000000">exe path: /home/myname/myrepo/build/myexe</font=
 ></div><div><span style=3D"color:rgb(0,0,0)">```</span></div><div><br></div=
 ><div><span style=3D"color:rgb(0,0,0)">&gt; The Linux man page doesn&#39;t =
 say anything about normalization</span></div><div>I think &quot;the actual =
 pathname&quot; in the doc means the normalized path. (I&#39;m not sure tho.=
 )</div><div><br></div><div>Well, I just thought it could be a bug because i=
 t worked in a different=C2=A0way from other=C2=A0unix=C2=A0variants.</div><=
 div>Idk if there is a rational reason for procfs to normalize paths, or if =
 it&#39;s just a matter of preference.<br></div><div>It&#39;s ok to close th=
 is PR if you say it&#39;s an expected behavior.</div></div>
 
 --000000000000c70481061a23ade4--