bug#37249: console shell upon login is not ~/.guix-profile/bash -- is this always/never ok?

[Bengt Richter]

On +2019-09-07 16:50:12 +0800, 宋文武 wrote:
> Bengt Richter <address@hidden> writes:
> 
> > Hello,
> >
> > In the pursuit of causes for problems as yet not clear enough to
> > post as bugs, I am looking for ambivalences in name searches
> > in /gnu/... and /(the-rest).
> 
> Hello, I think most guix packages (some won't or require manual
> configurations) will work on a foreign GNU/Linux distribution, and guix
> shouldn't cause problems for the distribution.
>

Hi ???iyzsong,

Thank you for caring to answer, and for your time working on it!

Unfortunately for me, perhaps, I am interested in pursuing purity
in the definition of systems, so "shoulds" are not that reassuring ;-)

I think your advice,

   > "... you might try the guix system if have so much
   > choices trouble you :-)

may be the easiest way to improve my current situation, so
I will see about doing that. Thanks :)

[...]

> 
> After login, user's shell program as specified in /etc/passwd will be
> executed.  So you should have '/usr/bin/bash' or '/bin/bash' in
> /etc/passwd, and your $PATH have '$HOME/.guix-profile/bin' before
> '/usr/bin', so when type 'bash' in a shell, the guix one got executed.
> 

Yes, but I don't normally type bash -- I type the name of some script
I've written and put in ~/bin, and it was typically written years ago
with a #!/usr/bin/bash first line, and I don't want to have to modify
all those ;-) Especially those that I might have put in a personal git
repo.

Would I have to, to migrate all those little helpers to my GuixSD ??

[...]

> > [13:42 ~/bs]$ which -a bash
> > /home/bokr/.guix-profile/bin/bash
> > /usr/bin/bash
> > [13:43 ~/bs]$ which -a bash|xargs readlink -f|while read line;do echo -ne 
> > "$line:\n    "; file "$line";done
> > /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash:
> >     /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash:
> >     ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
> > linked, interpreter
> >     
> > /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2,
> >     for GNU/Linux 2.6.32, not stripped
> > /usr/bin/bash:
> >     /usr/bin/bash: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
> > dynamically linked,
> >     interpreter /lib64/ld-linux-x86-64.so.2, 
> > BuildID[sha1]=21a51cb5f7d727370e4d8099d283d7cd20222571,
> >     for GNU/Linux 3.2.0, stripped
> >
> > Are the differences possibly dangerous?
> 
> It's totally OK, you can use both :-)
>
Until I have to diagnose a difference in behaviour ;-)
 
> >
> > Looking for dependencies outside of /gnu from within /gnu, I grepped the 
> > whole
> > as you see below. I am sure most of this is fine and coming out of 
> > documentation
> > and stuff meant for other than normally booted runtime. But does it all 
> > look ok?
> >
> > Or is my foreign-host twilight-zone shared ArchLinux/guix namespace really 
> > not
> > meant to be. I.e., is guix really defined to use /usr/ as a trusted base 
> > namespace
> > when it is defined by e.g. linux-libre in GuixSD ?
> >
> > Where would be the best docs to read about the guix name and environment 
> > rationales?
> 
> There are no 'namespace' involed, guix and your ArchLinux packages share
> the same filesystem.  And guix binaries are self-contained, they can
> work without any dependenices outsite of /gnu (sometimes they will use
> what's available in PATH, etc. which may be provided by your distribution).
>
I meant namespace in the general sense of a "space" to look for the meaning
of a name in, sorry to abuse the term.

Anyhow, that "sometimes" leaves me guessing ;-) 
> >
> > Ok, here is the grep:
[...]
> >     162 #!/usr/bin/env python3
> >     167 #!/bin/bash
> >     169 #!/usr/bin/env python
> >     207 
> > #!/gnu/store/iqx98v4rnw26n4qn555l4pbj96navxiv-python2-2.7.15/bin/python
> >     209 
> > #!/gnu/store/g87hamjyipk1j6dfq5pjfzfnfb64spbv-python2-2.7.15/bin/python
> >     228 #!/bin/sh
> >     292 
> > #!/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin/false
> >     292 
> > #!/gnu/store/8z9avbgm73nzrbkhscps68gcpfipgllc-bootstrap-binaries-0/bin/false
> >     319 #!/gnu/store/dna8kpb00kq176rz8x69yy4j33my2q55-perl-5.28.0/bin/perl 
> > -w
> >     362  #!/bin/bash
> >    1589 #!/gnu/store/dna8kpb00kq176rz8x69yy4j33my2q55-perl-5.28.0/bin/perl
> >    2706 
> > #!/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash
> >    3294 
> > #!/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh
> >    3871 #!/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash
> > -----------------------------------------------------
> 
> Yeah, a guix package should patch all those shell interperters from
> /bin, /usr/bin, etc to the store path under /gnu/store, but may miss
> some cases (which should be fixed).
> 
I can live with work in progress ;-)

[...]

> > I have set SHELL=/home/bokr/.guix-profile/bin/bash in ~/.bash_profile,
> > but as seen, that doesn't take effect for the immediate login shell.
> >
> > I wonder if I could exec it at the end of ~/.bash_profile -- or even as the 
> > first and only thing, hm...
> 
> Both should work, but you might try the guix system if have so much
> choices trouble you :-)
> >
Actually, neither exec worked the ways I tried. Idk, maybe by design, so as
not to allow exec to replace the process that catches seg faults etc and
cleans up on logout.

> > Hope someone can point to to enlightening reading re names in guix and its 
> > environments. TIA ;-)
> >
> > Bengt Richter
> 
> I'm not sure what you mean about "names" and "environments", in the
> low-level, they are:
> 
> filesystem:
>   guix use /gnu, /var/guix, /var/log/guix, and $HOME/.guix-profile, your
>   distribution doesn't use those, so guix can live within it happily.
> 
> environment variables:
>   PATH, MANPATH, INFOPATH (and more...), both guix and your distribution
>   share the same ones, so there maybe some conflicts.
>
Yup, I am experiencing those ;-)
 
> Hope it helps!
Yes, actually. Thank you!

Regards,
Bengt Richter