Installer shouldn't replace bashrc

I can agree with most points… but touching users home is not what we do on the installer … and if user is using the installer in a special way, it indeed can happen that it does something like it does in the case here… installer is running useradd and there is no option to reuse users home implemented for now. So all configs are only copied to create a new user. It does not check if there is already a users created config structure, because it assumes a clean install.

And as i mentioned already… bash package ships skel bashrc also.

 Package Contents




That’s a crime against humanity!!


1 Like

…but, cp has backup features:
Example of my method to copy dot files to a pre-existing user’s $HOME (in my own custom desktop)

# Copy/replace base dotfiles, keeping backups
cp --backup  -S ".bspd-bak" "$BSD_DATA"/bsp-bashrc  "$HOME/.bashrc"

# Copy default configuration files locally, without overwriting existing files
cp -rn "$BSD_DATA"/config/* "$XDG_CONFIG_HOME"/

But it could be possible that we can configure useradd to bail out if the users home folder already exist… and the option to reuse user home would be nice too… also i do not have a clue if it will do any good… it would be always better to not reuse the configs and instead back them up and copy back what you need manually… automating this to create a fully working setup? will be a nightmare from scripting it …
Possible to backup automatically so you can reuse your configs manually after first boot… and copy personal files back in the new user-home folder…


i do not say it is not possible… but it is simply not implemented.


Technically that what makes most sense, if you’re about to do that.

Personally i agree with you here, but we live in a society (c)


What you talking about Willis? :laughing:

Edit: Is this the We-feeling?

1 Like

I think the opposite view is more fit. “What is bad about it?”

IMHO, if there is/are custom environment variables, or other configs/aliases that are considered set with an EnOS system, then you could consider not implementing it, or finding a workaround method. Else, saving a possibly existing user file is a nice feature (nice touch :wink: ).

It already does this.

yes i agree 100% and it will be not that hard to check if user home with the name exists already and rename it p.e. like i mentioned earlier as my recommendation to save the home directory… it could also create a hint or something windows alike… creating a folder named old-files :wink:

The point is still valid aside from the automatic options to partition on manual partition you can do a lot of wrong things that will create a non-working install … let the installer fail or erase data… it will not be possible to remove all danger from the intall-process…

It is something to start working on to have a way to reuse existing homes in a way that society (c) can handle indeed.


Besides what @petsam said, it doesn’t seem related to useradd and friends because the contents of the replaced .bashrc are completely different from the /etc/skel/bashrc. As I mentioned, the contents seem related to the liveiso.

1 Like

Oh…now that’s definitely bug then :laughing:

Except the contents are NOT the same as from /etc/skel, so there is definitely something explicitly copying some .bashrc there.

Here’s the contents of the bashrc:

Yes, it is being installed by a script.

We are already looking at it and deciding what we will do going forward but it is something that will come in a future release, not an immediate change.

What I don’t understand is: why replace the user’s bashrc? Why not replace the system one (/etc/bash.bashrc) instead? There doesn’t seem to be anything in there that relies on it being the user’s bashrc file.

1 Like

It is code that has been there since long ago. Trying to solve the history of it is pointless.

1 Like

Fair point, but then it’s probably better to replace the system bashrc (which is guaranteed to be pristine and fairly expected to be changed by a new installation) than try to come up with complex solutions to detect if the user home exists, backup files, etc.
Either way, replacing user’s files behind their backs without backups or at least some warning is a big no-no in my book.

It’s nothing like that.
We are talking about an installation procedure, not a package installation, or a system utility that does that.
Installation is happening once, and when… installing (a new system). Then, the expected (normal) situation is that you don’t select a previously used partition for $HOME, without knowing what you are doing. If you do it, you should know, or have searched for info about it. :person_shrugging:
Not for inexperienced users.

We were talking about cases that experienced users might choose. I am sure OP won’t blame EnOS installer for the issue, rather trying to improve it with feedback :wink: .

Edit: :rofl:

I am really sorry! I was out of focus :face_with_head_bandage: :joy:

I am sure the team will find a way to improve this, although with a 3rd party installer (especially Calamares) this is quite difficult. :cry:

1 Like

Well I knew what I was doing, and didn’t expect to have lost my .bashrc. I’ve used many distros before and can’t remember any distro that simply replaces a user’s file like that. IMHO replacing existing user files without explicit warning or consent should be a frowned upon.

Unfortunately if I did search before doing, I would have found nothing, as I searched this forum before posting.

I’m an experienced user, and AFAIK EnOS is not exactly aimed at inexperienced users either. I’m OP and I blame both myself and EnOS for the issue, but also try to improve it with feedback.
In fact I’m surprised this didn’t come up before, since I expected more experienced users would use EnOS and reuse their home directories. Perhaps no one bothered to bring it up. Or perhaps I should have been wiser and more cautious.

1 Like

as i mentioned already there is no reuse home option on the installer implemented.
The installer is set up to install a new home and user.
But as dalto mentioned we will go to resolve the issue for a future release.