From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#30265: Fish shell has wrong path variables Date: Wed, 19 Sep 2018 22:39:19 +0200 Message-ID: <87o9ctdxxk.fsf@gnu.org> References: <87pnx9yhsx.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47535) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2jIW-0002NF-SN for bug-guix@gnu.org; Wed, 19 Sep 2018 16:42:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g2jIT-0000c3-UL for bug-guix@gnu.org; Wed, 19 Sep 2018 16:42:08 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:41799) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g2jIQ-0000Tn-Fv for bug-guix@gnu.org; Wed, 19 Sep 2018 16:42:04 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g2jIQ-0007UM-Bc for bug-guix@gnu.org; Wed, 19 Sep 2018 16:42:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87pnx9yhsx.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Wed, 19 Sep 2018 11:09:50 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Pierre Neidhardt Cc: meiyo.peng@gmail.com, 30265@debbugs.gnu.org Hi Pierre, Pierre Neidhardt skribis: > I think Ricardo got a hunch of what's happening, except that it's not > about cache files in the user home's directory. Instead, Fish seems to > record the path to the graft source. A grep in the fish folder does not > seem to reveal anything, nor does `strings > /gnu/store/...-fish.../bin/fish`. > > Could this be a grafting issue? Like what was recently mentioned about > Racket? It may well be a reference that doesn=E2=80=99t get properly grafted. We c= an see it when running the grafted fish under =E2=80=98strace=E2=80=99. The culprit is this bit from fish.cpp: // Fall back to what got compiled in. debug(2, L"Using compiled in paths:"); paths.data =3D L"" DATADIR "/fish"; paths.sysconf =3D L"" SYSCONFDIR "/fish"; paths.doc =3D L"" DOCDIR; paths.bin =3D L"" BINDIR; The =E2=80=9CL=E2=80=9D here means these are =E2=80=9Cwide string=E2=80=9D = literals, and indeed, the =E2=80=9CUsing=E2=80=A6=E2=80=9D string above looks like this in the ELF fi= le: 001140d0: 5500 0000 7300 0000 6900 0000 6e00 0000 U...s...i...n... 001140e0: 6700 0000 2000 0000 6300 0000 6f00 0000 g... ...c...o... 001140f0: 6d00 0000 7000 0000 6900 0000 6c00 0000 m...p...i...l... 00114100: 6500 0000 6400 0000 2000 0000 6900 0000 e...d... ...i... 00114110: 6e00 0000 2000 0000 7000 0000 6100 0000 n... ...p...a... 00114120: 7400 0000 6800 0000 7300 0000 3a00 0000 t...h...s...:... The DATADIR literal is similarly =E2=80=9Chidden=E2=80=9D, and thus the gra= fting code doesn=E2=80=99t see it. Possible fixes include: 1. Finding a way to make the run-time detection in =E2=80=98determine_config_directory_paths=E2=80=99 to always work with= out going to the fallback case where it relies on string literals. This could be done by attempting to read /proc/self/exe (on GNU/Linux) instead of relying on argv0. 2. Using =E2=80=9Cregular=E2=80=9D strings, or at least arranging to stor= e DATADIR & co. in regular =E2=80=9Cconst char=E2=80=9D arrays. Maybe something l= ike: static const char datadir[] =3D DATADIR; =E2=80=A6 paths.data =3D L"" + datadir + L"/fish"; It probably takes some more casts from char[] to std::string to wcstring, but you get the idea. ;-) Thoughts? Ludo=E2=80=99.