Please, oh please, ask, or at least warn, about overwriting ~/.zshrc on installation

[ahills]

Today is a little worse than it was before installing oh-my-zsh.

[robobenklein]

It copies the old .zshrc to .zshrc_bkp or .zsh.pre-oh-my-zsh, so it's still there if you want to undo.

[ahills]

Right, and if the installer runs twice, the backup is nuked. A warning anywhere, especially in the installation notes, would be a service to new users.

[robobenklein]

I think a good fix for this (including the note that this will overwrite) would be to backup the .zshrc in a logfile type rotation.

Or we could just instead backup to zshrc.backup-$(date) and we wouldn't have to worry about losing backups. That would be only one line change to the install script, easy enough.

[apjanke]

Similar request open in #2499.

It's about time we fixed this. Here's a PR: #4391. It was a bit more than one line, but it's still quite simple.

It does the timestamped-backup thing to keep the existing uninstall.sh behavior's simple.

[afeinman]

Any chance of getting this fixed, 4 years later?

[mcornella]

Hey @afeinman it's been a long journey but I finally got there! I pull @apjanke's fix in #5169 and it's now ready for testing.

If you want to help speed up the testing and merge (which should happen early next week), you can wget or curl it from the URL https://raw.githubusercontent.com/mcornella/oh-my-zsh/refactor-installer/tools/install.sh. Read the comments at the top of the script to know how to call it.

Thanks!

[mcornella]

Closed by #5169.

[tasdflkjweio]

This is still a problem.

[Julianouyang]

.zshrc still got overwritten in 2022. Amazing. Just amazing

[rwmitchell]

It has to get overwritten to work. Didn’t it make a backup copy first?

[geeofree]

For those that are here and want to not have their zshrc get overriden: see this comment #8209 (comment). Or if you're too lazy to click:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" "" --keep-zshrc

[goblinwtf]

I let my former boss install oh-my-zsh and it overwrote all of his many macros, especially the ones to prod db/server/etc... it's a pity I didn't google this page back then :X

[mcornella]

The old file is renamed to .zshrc.pre-oh-my-zsh, it is never deleted.

[ahills]

That's only true the first time you run it. :) If you rerun the installer, say, because you wanted to take a different path, or something didn't go the way you expect, then that backup is obviously overwritten with the first oh-my-zsh's contents—in other words, deleted. This is what I was expressing in my first reply above.

The simplest possible mitigation is to check whether a backup has already been created before writing, so that different behavior can be invoked—maybe prompting the user, or picking some additional, unique, suffix.

Obviously, as a user, it's my responsibility to back up my data; but, in my defense, the installer doesn't (or didn't, back when I filed the issue) warn you that your ~/.zshrc is being replaced instead of modified, and the note about the backup is misleading without some warning that running it a second time will cause permanent data loss.

[carlosala]

I'll carry that. We should backup as many zshrc as needed. Thanks for the report!

[ahills]

It looks like #5169 actually fixed this issue:

https://github.com/ohmyzsh/ohmyzsh/pull/5169/files#diff-5dc310979be51acc76eb748ef379630b65614b5a4132fc5a870019ade043935bR113-R124

This check is basically exactly what I had in mind. You could theoretically still lose data by running multiple installers per second, but there's only so much a developer can do to save us from ourselves.

[carlosala]

@ahills what you reported has been fixed already, you can check the implementation here

I tested it now and it's working as expected

[mcornella]

To be extra explicit about the current behavior, this is what happens:

1. If .zshrc is not found, write and modify the template zshrc file to ~/.zshrc.
2. If .zshrc is found, start the back up process:
   1. If ~/.zshrc.pre-oh-my-zsh exists, back it up to ~/.zshrc.pre-oh-my-zsh-<YYYY-mm-dd_HH-MM-SS> (time when the installer runs). If this destination file exists, abort the sequence and the installer.
   2. After ~/.zshrc.pre-oh-my-zsh is backed up, move .zshrc to it.
   3. Only then write the template zshrc file to ~/.zshrc.

I understand the current behavior is confusing, but all this information is printed on the screen while the installer is running, so please pay attention to the messages.

[ahills]

You're right! Looks like it was fixed in 43b3126 over three years ago. Maybe @tasdflkjweio, @Julianouyang, & @kris-jobs can find their backed-up copies then?

[mcornella]

Documented this in https://github.com/ohmyzsh/ohmyzsh/wiki/FAQ#my-zshrc-file-was-deleted-on-install.

[upnorth]

Why can't omyzsh simply have it's own conf file and just add itself to the main one somehow, saving it to a backup is better than only overwriting it but why would restoring something from a backup ever be part of a decent installation process anyway? Not super familiar with the best practicies of cli stuff but it seems like a very backwards and confusing approach...

[dflow]

amazing still overwrites the source! Give a Heads up!
where is the backupfile file ---> found it on /.zshrc.pre-oh-my-zsh

[samuliraty]

Why can't omyzsh simply have it's own conf file and just add itself to the main one somehow, saving it to a backup is better than only overwriting it but why would restoring something from a backup ever be part of a decent installation process anyway? Not super familiar with the best practicies of cli stuff but it seems like a very backwards and confusing approach...

This seems like the obvious thing to do, wonder why this less intuitive approach of discarding the users config was chosen

[kartikrajjj]

Please add markers around when editing .zshrc so we can atleast remove it. I spent a week editing my .zshrc at my new company and all of the progress just went 💥

Opened #12330

[rwmitchell]

Why did you lose it? OMZ makes a backup copy of it