bash genfun_has_readline

[Checko55]

Hi guys,

after an upgrade some days ago I get following message from bash when logging in:

-bash: genfun_has_readline: command not found

Since that the color prompt does not work properly anymore and all my aliases as well.
It is the same for root and my users.
My bashrc is located in /etc/bash
I tried to recompile readline and bash without any changes in that behaviour.

I just saw that in /etc/bash a bashrc.d was created with two new files like:
10-gentoo-color.bash
10-gentoo-title.bash

I couldn't find a solution so far.

Any hints what goes wrong here?

thank you in advance

Checko

[Ionen]

Did you update /etc/bash/bashrc with the new one shipped alongside these? May not have been automatic if you have modified it.

It defines genfun_has_readline for the bashrc.d files to use, if you were modifying the bashrc itself I'd suggest moving your custom configs to bashrc.d as well and just keep the original (gentoo moved its more custom stuff like colors there as well for the sake of modifying or deleting as wanted).

[Checko55]

Hello!

I did not update with the new one and have only the one with my customizations like aliases.

I put my bashrc file in /etc/bash/bashrc.d/ with no effect.
The aliases and color settings still do not work.

The documentation tells nothing about these settings in those two files (title and color) in bashrc.d

[freke]

I got this during switch from amd64 to ~amd64 - this included a glibc-update which prompted me to reboot, was gone after reboot.
Not sure exactly what package/ebuild caused the '-bash: genfun_has_readline: command not found' (I believe I replaced the bashrc with the new during cfg-update - not 100% though)

[Checko55]

Hi,

no matter where I put the bashrc, it has no effect or any changes visible.

Can I get the recommended configs from etc-update again? Maybe I can do a merge then...

[freke]

Hi,

no matter where I put the bashrc, it has no effect or any changes visible.

Can I get the recommended configs from etc-update again? Maybe I can do a merge then...

With the gentoo-repos in default location you can find the files in

Code: Select all

/var/db/repos/gentoo/app-shells/bash/files

Specifically the bash_logout, the bashrc-r1 and the files in bashrc.d
bash_logout and bashrc are meant to go to /etc/bashrc - while the files in bashrc.d belongs in bashrc.d
(the dot-bash files goes to /etc/skel/.bash*)

or you can emerge -va1 app-shells/bash

[Checko55]

Hi again,

that was it.
I re-emerged bash like you wrote and used the recommended bashrc.

Customization are then taken from the bashrc.d files.

thanks for your help guys!

regards
Checko

[sunox]

I'm having the same issue ever since I updated this morning. I normally update just about every day but this time I let things sit for maybe a week or more.

I replaced .bashrc with the "bashrc" file in /var/db/repos/[...] but it made no difference. Emerging bash one-shot doesn't seem to replace any config files, nor does it create them after I remove the existing ones.

[Banana]

Please have also a look here: viewtopic-t-1169476-highlight-.html
Similar problems and maybe a solution for you.

[RumpletonBongworth]

Please have also a look here: viewtopic-t-1169476-highlight-.html
Similar problems and maybe a solution for you.

That thread concerns a dissimilar problem. The one described by this thread will occur where users do not merge the updated /etc/bash/bashrc file, be it with dispatch-conf or by otherwise manually reviewing and accounting for the changes therein.

The new bashrc file contains a function that checks whether readline support it available. This function is called upon to determine whether certain shell options can be enabled in interactive instances of bash. The reason for bothering is that Gentoo permits for app-shells/bash to be compiled without readline support and there exists a minority of users that go out of their way to do that. For such users, the old bashrc would always produce errors complaining of invalid shell options.

Checko55, please note that package upgrades never directly replaces files beneath /etc that have been modified by the user. This is to protect against such modifications from being destroyed. In this case, if you list the (hidden) dotfiles under /etc/bash/, you should find that there is a new copy of the bashrc file pending. Users are generally expected to use the dispatch-conf utility to review and merge such changes, though this form of maintenance can also be conducted manually.

Sometimes, people accidentally 'zap' the new file in the course of reviewing changes with dispatch-conf. In that case, the simplest solution that can be generally offered is to re-emerge bash with the noconfmem option:-

Code: Select all

# emerge --oneshot --noconfmem bash
# dispatch-conf

[RumpletonBongworth]

I replaced .bashrc with the "bashrc" file in /var/db/repos/[...] but it made no difference. Emerging bash one-shot doesn't seem to replace any config files, nor does it create them after I remove the existing ones.

You should not do this. The $HOME/.bashrc file isn't intended to contain vendor-supplied code other than in one potential respect: when a new user account is created, the contents of the HOME directory may be populated according to the contents of /etc/skel. As such, the default ".bashrc" just performs a check for interactive shells and leaves it to the user to decide whatever else they want to do with it. It's unrelated to the problem.

EDIT: As noted by the previous post, using the --noconfmem option would have re-queued the new systemd-wide bashrc file for your review, though this isn't usually necessary other than under irregular circumstances.

[Hammett]

I had this problem today.

I normally discard changes from emerge as it usually wants to overwrite any customisation done on the config file. Things like bash and mpd come to mind quickly, but I'm sure there are plenty more.

I believe a news would have been nice in this scenario to alert users that this config update is "mandatory" and how to proceed to restore the customisation done.

[RumpletonBongworth]

I believe a news would have been nice in this scenario to alert users that this config update is "mandatory" and how to proceed to restore the customisation done.

Firstly, your feedback is welcomed. As the person that submitted that the changes, I am keeping a close eye on any posts concerning this.

Strictly speaking, it is not a mandatory update. If you wish to customise /etc/bash/bashrc directly, effectively nominating yourself as its maintainer, and ignore all future updates, you may continue to do that. In that case, you are not obliged to source the drop-ins either. One of the reasons for splitting colourisation and title setting out is that it's pretty heavy-handed and opinionated to begin with. One of the ideas was that such things could then be suppressed by INSTALL_MASK for the intersection of people that don't care for it but also don't particularly wish to volunteer themselves as per-host /etc/bash/bashrc maintainers either. My perspective was that, for a vendor-supplied bashrc file it was all a little over the top and that it would be a net benefit to be ship a much simpler one that benefits from remaining under vendor control for a majority - an overwhelming one I suspect - that have little interest in touching it, and where subtle but meaningful improvements can be made, such as not raising errors for USE="-readline", protecting against GLOBSORT in the upcoming bash-5.3 and whatever else may arise. Certainly, you could make the case that it could have remained as a monolithic file.

Regarding the provision of a news item, perhaps you are right. It wouldn't have been difficult to whip something up and, with the benefit of hindsight, it should have at least been considered. Although, I can say from experience that we would still be seeing threads regarding botched /etc updates which, lest we forget, is what this particular thread concerns. There will always be a subset of users that just don't read news or end up responding to it in a way that begets more questions than answers. And there will always be users that fumble config updates. Additionally, the einfo messages should have been warnings originally, though they are now.

On a purely technical basis, I think it was probably a mistake to make a drop-in depend on a function that's not declared within the same unit. That can easily be changed so I'll submit a patch to do that for the next round of revisions.

[Hammett]

Strictly speaking, it not a mandatory update. If you wish to customise /etc/bash/bashrc directly, effectively nominating yourself as its maintainer, and ignore all future updates, you may continue to do that. In that case, you are not obliged to source the drop-ins either.

It kind of is if you ignore the updated config files and suddenly the functionality that you expect is no longer there. You will understand I am no fit for maitaining bashrc at all past the basic aliases and PS1 prompt

Regarding the provision of the news item, perhaps you are right. It wouldn't have been difficult to whip something up and, with the benefit of hindsight, it should have at least been considered. Although, I can say from experience that we would still be seeing threads regarding botched /etc updates which, lest we forget, is what this particular thread concerns. There will always be a subset of users that just don't read news or end up responding to it in a way that begets more questions than answers. And there will always be users that fumble config updates. Additionally, the einfo messages should have been warnings originally, though they are now.

Agreed, there will be users that do not read the news, but then it's their responsibility what they do with their system, and I am all in for a good old RTFM. I trust that when you guys issue news, they are important and should be read. It is not that you send every day, so when they come, they are important

This is not a complaint whatsoever. I am eternally grateful for the work you guys do with Gentoo. I was able to quickly search the issue, found this thread, read through it and made the necessary changes, it is really not a biggie. It is just that I wish instead of having this surprise, remember that I did not apply a bashrc update, google the issue, find the thread and make changes, I could have read a news article and I would have made the same changes straight away

Thanks for your response and work

Kind regards

[RumpletonBongworth]

You will understand I am no fit for maitaining bashrc at all past the basic aliases and PS1 prompt

If that was the only reason for editing the system-wide bashrc then you might be better off creating a drop-in such as /etc/bash/bashrc.d/99-local.bash to contain your preferences. I would have issued much the same advice prior to the app-shells/bash update.

[Hammett]

You will understand I am no fit for maitaining bashrc at all past the basic aliases and PS1 prompt

If that was the only reason for editing the system-wide bashrc then you might be better off creating a drop-in such as /etc/bash/bashrc.d/99-local.bash to contain your preferences. I would have issued much the same advice prior to the app-shells/bash update.

Indeed, this is what I have done now. Also, this system is almost 18 years old (never re-installed Gentoo on this machine).... my knowledge 18 years ago was not the same... and I liked risk a tad more

[sunox]

The weird thing is I don't think I have made any config file edits beyond sourcing a file in .bashrc (one line). It's still not clear what I have to do, but I'll read the comments here a bit more carefully. This feels like a bug to me.

[sunox]

I replaced .bashrc with the "bashrc" file in /var/db/repos/[...] but it made no difference. Emerging bash one-shot doesn't seem to replace any config files, nor does it create them after I remove the existing ones.

You should not do this. The $HOME/.bashrc file isn't intended to contain vendor-supplied code other than in one potential respect: when a new user account is created, the contents of the HOME directory may be populated according to the contents of /etc/skel. As such, the default ".bashrc" just performs a check for interactive shells and leaves it to the user to decide whatever else they want to do with it. It's unrelated to the problem.

EDIT: As noted by the previous post, using the --noconfmem option would have re-queued the new systemd-wide bashrc file for your review, though this isn't usually necessary other than under irregular circumstances.

I just deleted my .bashrc file and put my customizations in bashrc.d (or whatever it is called) and everything seems fine now. I could have swore that my .bashrc had a bunch of stuff in it by default, but maybe I'm wrong?

[RumpletonBongworth]

I just deleted my .bashrc file and put my customizations in bashrc.d (or whatever it is called) and everything seems fine now. I could have swore that my .bashrc had a bunch of stuff in it by default, but maybe I'm wrong?

Yes, you are are. See my previous post concerning /etc/skel and, in particular, /etc/skel/.bashrc. That is the file that would have been copied to your home directory at the time that your created your user account. None of this has anything to do with the problem that Checko55 opened this thread for, though.

[cfgauss]

...if you were modifying the bashrc itself I'd suggest moving your custom configs to bashrc.d as well and just keep the original...

I am having trouble with root only as I have customizations in /root/.bashrc. Do your instructions mean

Code: Select all

# cp /root/.bashrc /etc/bash/bashrc.d/bashrc

only?

[RumpletonBongworth]

...if you were modifying the bashrc itself I'd suggest moving your custom configs to bashrc.d as well and just keep the original...

I am having trouble with root only as I have customizations in /root/.bashrc. Do your instructions mean

Code: Select all

# cp /root/.bashrc /etc/bash/bashrc.d/bashrc

only?

They aren't instructions; it was merely a recommendation to Hammett pertaining to his particular justification for deliberately ignoring the /etc/bash/bashrc update in dispatch-conf, thus self-inflicting the problem that Checko55 described in the first post. If you are experiencing that same problem then you, too, have ignored the config update and you need to merge it. Again, this thread really has nothing to do with ".bashrc" (as in dot bashrc) at all. To help you specifically, I would need to know what the trouble is exactly. Does it concern genfun_has_readline errors or something else?

[RumpletonBongworth]

am having trouble with root only

Reading this a second time - and with the benefit of having slept on it - I could interpret your trouble as simply being one of how to make your root-only customisations be applied to all users rather than just the root user alone. Is that what you meant? If it is then yes, you may create your own file under /etc/bash/bashrc.d/ or even move an existing ~/.bashrc there. However, there are several things to be aware of:-

• their names must have a suffix of either ".sh" or ".bash"
• their names must not begin with a dot
• they will be sourced in alphabetical order

So, for example, you could run:

Code: Select all

# mv ~/.bashrc /etc/bash/bashrc.d/bashrc.bash

Personally, I wouldn't call it bashrc.bash; rather, something like 99-local.bash or 99-custom.bash. Nevertheless, it would work.

EDIT: added additional bullet point regarding dots in names

[cfgauss]

Does it concern genfun_has_readline errors or something else?

My ~/.bashrc provides the expected customization. However, for root

Code: Select all

# . ~/.bashrc
bash: genfun_has_readline: command not found

Any hints on fixing this will be gratefully received.

[RumpletonBongworth]

Does it concern genfun_has_readline errors or something else?

My ~/.bashrc provides the expected customization. However, for root

Code: Select all

# . ~/.bashrc
bash: genfun_has_readline: command not found

Any hints on fixing this will be gratefully received.

OK. In that case, I would refer you to my first post in this thread. You should begin by running the dispatch-conf command and checking whether it presents a new /etc/bash/bashrc file to be merged/installed (it should).

[RumpletonBongworth]

Additionally, cfgauss, please show the current contents of your ~/.bashrc file. Normally I would not need to ask but there is definitely something strange in yours.

EDIT: Though it should be obvious, I meant for the root user. Thus, the /root/.bashrc file.