Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
bash genfun_has_readline
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
cfgauss
l33t
l33t


Joined: 18 May 2005
Posts: 716
Location: USA

PostPosted: Tue Jun 18, 2024 2:08 pm    Post subject: Reply with quote

Code:
$ sudo emerge -1 --noconfmem bash
...
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) app-shells/bash-5.2_p26-r4::gentoo
>>> Installing (1 of 1) app-shells/bash-5.2_p26-r4::gentoo
>>> Completed (1 of 1) app-shells/bash-5.2_p26-r4::gentoo
>>> Jobs: 1 of 1 complete                           Load avg: 2.44, 0.70, 0.32
...
$ sudo dispatch-conf
$ sudo su
bash: genfun_has_readline: command not found

Here is /root/.bashrc.
Back to top
View user's profile Send private message
RumpletonBongworth
n00b
n00b


Joined: 17 Jun 2024
Posts: 59

PostPosted: Tue Jun 18, 2024 2:32 pm    Post subject: Reply with quote

cfgauss wrote:
bash: genfun_has_readline: command not found[/code]
Here is /root/.bashrc.

For some reason, you copied an outdated /etc/bash/bashrc to /root/.bashrc. There is nothing in the latter copy that is appropriate or useful in a per-user context so you can replace it with the default skeleton file.
Code:

cp /etc/skel/.bashrc /root/.bashrc

The issue will then be resolved.
Back to top
View user's profile Send private message
RumpletonBongworth
n00b
n00b


Joined: 17 Jun 2024
Posts: 59

PostPosted: Tue Jun 18, 2024 4:50 pm    Post subject: Reply with quote

I shall be proposing that a warning be added to /etc/bash/bashrc making it clear that it should never be copied into a home directory as a ~/.bashrc file. I had never imagined that people would actually do this but it is now quite clear that some do. An especially problematic consequence is that the bashrc.d files end up being sourced twice. Please, never do this! By all means, customise your shell as you see fit but don't just blindly copy random files from /etc. Should you require a template to start with, then /etc/skel/.bashrc would be it. Indeed, that is the file that gets copied into newly created home directories upon user account creation.
Back to top
View user's profile Send private message
cfgauss
l33t
l33t


Joined: 18 May 2005
Posts: 716
Location: USA

PostPosted: Tue Jun 18, 2024 5:06 pm    Post subject: Reply with quote

RumpletonBongworth wrote:
Code:

cp /etc/skel/.bashrc /root/.bashrc
The issue will then be resolved.

It is. Many thanks. I will start with /etc/skel/.bashrc as the basis for customizations in the future.
Back to top
View user's profile Send private message
RumpletonBongworth
n00b
n00b


Joined: 17 Jun 2024
Posts: 59

PostPosted: Tue Jun 18, 2024 5:29 pm    Post subject: Reply with quote

cfgauss wrote:
I will start with /etc/skel/.bashrc as the basis for customizations in the future.

I have filed a bug regarding this matter.
Back to top
View user's profile Send private message
Doogman
Apprentice
Apprentice


Joined: 24 Sep 2004
Posts: 244

PostPosted: Wed Jun 19, 2024 3:25 am    Post subject: Reply with quote

RumpletonBongworth wrote:
I shall be proposing that a warning be added to /etc/bash/bashrc making it clear that it should never be copied into a home directory as a ~/.bashrc file. I had never imagined that people would actually do this but it is now quite clear that some do. An especially problematic consequence is that the bashrc.d files end up being sourced twice. Please, never do this! By all means, customise your shell as you see fit but don't just blindly copy random files from /etc. Should you require a template to start with, then /etc/skel/.bashrc would be it. Indeed, that is the file that gets copied into newly created home directories upon user account creation.


I don't think you have a very clear understanding on just how long the average Gentoo installation has been in service or when the support files in the home directory were created which are probably even older. Since I have the exact same .bashrc in the home directory as cfgauss posted you can be reasonably assured that at one time it was either SOP to copy /etc/bashrc for the home directory or this is where adduser sourced the .bashrc file years ago. I'm talking twenty years ago when Gentoo was the new and hot Linux distro.

It's not a hard fix, but lets just say if your .bashrc starts with more than below you might want to edit it down a bit.

Code:

# /etc/skel/.bashrc
#
# This file is sourced by all *interactive* bash shells on startup,
# including some apparently interactive shells such as scp and rcp
# that can't tolerate any output.  So make sure this doesn't display
# anything or bad things will happen !


# Test for an interactive shell.  There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
if [[ $- != *i* ]] ; then
        # Shell is non-interactive.  Be done now!
        return
fi


# Put your fun stuff here.
Back to top
View user's profile Send private message
RumpletonBongworth
n00b
n00b


Joined: 17 Jun 2024
Posts: 59

PostPosted: Wed Jun 19, 2024 4:47 am    Post subject: Reply with quote

Doogman wrote:
I don't think you have a very clear understanding on just how long the average Gentoo installation has been in service or when the support files in the home directory were created which are probably even older.

I have been using, managing, and discussing Gentoo systems for as long as the distribution has been called Gentoo. Indeed, I recall its origins as Enoch. I have no recollection of this ever being standard practice. I would be much more inclined to take you at your word if you were to provide concrete proof rather than take a potshot at my level of experience. As it stands, I can't help but be skeptical because there is no technical sense in guiding a user into installing a ~/.bashrc that is so formed. That is, I have to wonder which maintainer in their right mind would have determined that the following narrative makes any sense.

Quote:
Let's ship a relatively complex, opinionated system-wide bashrc that is default-sourced by interactive login shells. Let's also make it glob /etc/bashrc.d/* and source each path matched. Let's also guide users into copying this bashrc into their home directories, verbatim.

Still, I have seen maintainers do some very silly things in the history of this distribution. Let's assume that you are correct and that this was once SOP.

Firstly, it would indicate that your memory is better than mine on this particular detail and that I should not necessarily presume that cfgauss, sunosx et al weren't acting under instruction. Bravo, in that case. It will have transpired that I am imperfect.

Secondly, it does not change anything moving forwards. In particular, it would not diminish the premise of the bug that I have filed. Please note that I am seeking to improve the situation for users here. Whatever may have been the case ~20 years ago, it is improper to use /etc/bash/bashrc as a template in the present day. Further, and is also stated by the bug report, the average user can hardly be expected to infer or intuit this.

Thirdly, Gentoo has been providing release tarballs without skeleton /root bash files for as long as I can remember. I consider this to be a subtle matter of usability and have made that clear in the bug. It renders the home directory of the root user an outlier and I think that I am justified in claiming that this increases the probability of someone choosing to use /etc/bash/bashrc as a template, now and in the future. I stand by this claim, whether or not the commenters in this particular thread did so.

Fourthly, the forthcoming revisions of app-shells/bash will make it so that 10-gentoo-color.bash will not raise an error if sourced from any other unit than /etc/bash/bashrc itself. I have already conceded that it was a mistake to make the behaviour of the former contingent on the behaviour of the latter. Although, had this mistake not been made, the above-mentioned issues would not have been brought to the fore so it may yet turn out to be for the best in the end.
Back to top
View user's profile Send private message
Doogman
Apprentice
Apprentice


Joined: 24 Sep 2004
Posts: 244

PostPosted: Wed Jun 19, 2024 1:16 pm    Post subject: Reply with quote

RumpletonBongworth wrote:
I have been using, managing, and discussing Gentoo systems for as long as the distribution has been called Gentoo. Indeed, I recall its origins as Enoch. I have no recollection of this ever being standard practice. I would be much more inclined to take you at your word if you were to provide concrete proof rather than take a potshot at my level of experience. As it stands, I can't help but be skeptical because there is no technical sense in guiding a user into installing a ~/.bashrc that is so formed. That is, I have to wonder which maintainer in their right mind would have determined that the following narrative makes any sense.

You profess all this experience and yet your forum account is a whopping few days old. Was your earlier account banned for talking complete bollocks?

If you think I'm going to spend time digging through Gentoo history to find where a specific .bashrc originated you must be mad! It's more than a coincidence that a few of us have basically the same file, however. The reason you are taking pot shots is because after the latest sync several users are getting error messages apparently from changes you submitted. Why the changes, who knows? One would think by now the "bash" package and it's associated files wouldn't need to change much, but here we are...
Back to top
View user's profile Send private message
Banana
Moderator
Moderator


Joined: 21 May 2004
Posts: 1505
Location: Germany

PostPosted: Wed Jun 19, 2024 2:05 pm    Post subject: Reply with quote

Moderator note: Please be civil
_________________
Forum Guidelines

PFL - Portage file list - find which package a file or command belongs to.
My delta-labs.org snippets do expire
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 21970

PostPosted: Wed Jun 19, 2024 3:18 pm    Post subject: Reply with quote

Doogman wrote:
RumpletonBongworth wrote:
I have been using, managing, and discussing Gentoo systems for as long as the distribution has been called Gentoo. Indeed, I recall its origins as Enoch. I have no recollection of this ever being standard practice.
You profess all this experience and yet your forum account is a whopping few days old. Was your earlier account banned for talking complete bollocks?
Forum accounts are not required as a precondition to using Gentoo. RumpletonBongworth said he has extensive experience using Gentoo. He did not claim to be a long-time Gentoo developer. From some comments elsewhere, it appears that RumpletonBongworth authored the changes under discussion, but someone else committed them on his behalf, so he may not be a Gentoo developer at all. I have seen several threads where a user with a very new forum account shows up to ask a question about an old system, and indicates that they have never needed to post to the forums before. In this case, it may be that RumpletonBongworth only registered the account to be able to support this bash change. If so, we should be appreciative that he did not merely throw the change over the wall and walk away, leaving users to their own devices if it did not work perfectly on the first try.
Doogman wrote:
If you think I'm going to spend time digging through Gentoo history to find where a specific .bashrc originated you must be mad!
Not necessarily. Some people are very diligent about using version control on their personal configurations. Such a user might be able to answer the query quickly and easily by consulting the log from their version control system. If you are not the type of person to keep such meticulous records, then yes, it would be a burden to determine the origin of this file.
Doogman wrote:
It's more than a coincidence that a few of us have basically the same file, however.
If you all have the same file through independently making the same mistake, then that seems like a coincidence. If you all have the same file through following bad instructions, then yes, it's not just a coincidence, and we come back to the implied question: where and when was someone in authority telling users to create their dot-files this way? By extension, what was the motivation of pushing users to such an approach? Was it a good idea at the time (RumpletonBongworth says it was not, and absent a compelling reason we have not seen, I am inclined to agree). If it was once a good idea, when did it become a bad idea? If it was never a good idea, why did this hypothetical person push it?
Doogman wrote:
The reason you are taking pot shots is because after the latest sync several users are getting error messages apparently from changes you submitted.
RumpletonBongworth seems to be handling these problem reports quite politely. I would not call the responses "taking pot shots."
Doogman wrote:
Why the changes, who knows? One would think by now the "bash" package and it's associated files wouldn't need to change much, but here we are...
The justification for the changes can be found in the git commit log for the commits that introduced this. The log is considerably more detailed than most git logs I see, and suggests to me that the author wants people to understand the change and the decisions that led to it.
Back to top
View user's profile Send private message
RumpletonBongworth
n00b
n00b


Joined: 17 Jun 2024
Posts: 59

PostPosted: Wed Jun 19, 2024 4:23 pm    Post subject: Reply with quote

Hu wrote:
In this case, it may be that RumpletonBongworth only registered the account to be able to support this bash change.

Indeed I did. If anyone must know, I've been here before but elected to close that account. I don't feel obligated to say exactly when that account was registered but I'll put it this way: there are presently ~157502 registered accounts on this forum; my old account ID was within the three digit range.
Back to top
View user's profile Send private message
RumpletonBongworth
n00b
n00b


Joined: 17 Jun 2024
Posts: 59

PostPosted: Thu Jun 20, 2024 6:19 pm    Post subject: Reply with quote

As of bash-5.1_p16-r12, the drop-in that handles colour-related features is entirely self-contained and can no longer raise errors pertaining to readline, no matter what's in /etc/bash/bashrc or ~/.bashrc.
Back to top
View user's profile Send private message
RumpletonBongworth
n00b
n00b


Joined: 17 Jun 2024
Posts: 59

PostPosted: Fri Jun 21, 2024 2:08 am    Post subject: Reply with quote

Hu wrote:
If you all have the same file through following bad instructions, then yes, it's not just a coincidence, and we come back to the implied question: where and when was someone in authority telling users to create their dot-files this way?

I suspect the answer is never. As it happens, support for bashrc.d/ was added on 9th November 2014, and it may have taken a while after that for the revised bash ebuild to be stable keyworded. By definition then, nobody with the string "for sh in /etc/bash/bashrc.d/* ; do" - character for character - in their ~/.bashrc could plausibly have made it so prior to that date. So much for it being standard operating procedure 20 years ago. I also don't buy that Michał Górny, who was responsible for that change, or anyone on the base-system team would have sanctioned any advice to that effect. Nor do I buy that people try to run adduser for root accounts (!) or that it, or any other tool like it, has ever used anything other than /etc/skel as a basis to populate a home directory.

In any case, users that have a ~/.bashrc containing the above-mentioned string will now be issued a warning, along with guidance. This warning will appear no more frequently than once per the combination of booting and logging in. I shall continue to observe the forums in case there any questions in view of this.

EDIT: In fact, while Gorny authored the commit during 2014, it took until January 2016 for it to be pushed.
Back to top
View user's profile Send private message
wundermute
n00b
n00b


Joined: 27 Aug 2019
Posts: 8
Location: Brittany

PostPosted: Sat Jun 22, 2024 6:42 pm    Post subject: Reply with quote

Hello,
I got one of my boxes landing in the same behaviour. digging further it's because of the already told difference between 5.1 and 5.2

Code:

$ grep -r genfun_has_readline /etc/bash/bashrc*
/etc/bash/bashrc.d/10-gentoo-color.bash:if (( gentoo_color <= 0 )) || ! genfun_has_readline; then


Doing a diff between one host and another
Code:

37,38c37
< if (( gentoo_color <= 0 )) || ! genfun_has_readline; then
---
> # For direxpand to be missing indicates that bash is lacking readline support.
> if (( gentoo_color <= 0 )) || [[ ! $(shopt -p direxpand 2>/dev/null) ]]; then


which fixed the bork.
Back to top
View user's profile Send private message
RumpletonBongworth
n00b
n00b


Joined: 17 Jun 2024
Posts: 59

PostPosted: Sat Jun 22, 2024 7:02 pm    Post subject: Reply with quote

wundermute wrote:
I got one of my boxes landing in the same behaviour. digging further it's because of the already told difference between 5.1 and 5.2

Technically, it was either because you didn't merge the new, vendor-provided /etc/bash/bashrc or you're sourcing bashrc.d drop-ins from somewhere else, such as your ~/.bashrc. It has been discussed in some detail in this thread already. If the former scenario applies to you, you should definitely consider merging the update. If the latter applies to you, you should avoid doing that.

wundermute wrote:

Doing a diff between one host and another
Code:

37,38c37
< if (( gentoo_color <= 0 )) || ! genfun_has_readline; then
---
> # For direxpand to be missing indicates that bash is lacking readline support.
> if (( gentoo_color <= 0 )) || [[ ! $(shopt -p direxpand 2>/dev/null) ]]; then


which fixed the bork.

Yes, this change was made to avoid raising errors for the two aforementioned scenarios. That same change is also in 5.1, as was mentioned several posts above.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum