Some minor alteration concerning .zshrc.pre-oh-my-zsh

[greenwellness]

A suggestion, but would it be possible to copy the existing .zshrc file to .zshrc.pre-oh-my-zsh-$(date +%s) or the likes? I had a hanging install on password, had to kill it, then tried to install again and - of course - it overwrites my previous (correct) .zshrc file.

Obviously, I should have backed it up - and its not that great of a loss, but still. Don't know if this is desirable or if people fear it might clutter up ~ a bit too much on the .zfiles potentially.

[ncanceill]

Probably no need for a timestamp, just a counter like .zshrc.pre-oh-my-zsh.1.

In order to mitigate the side-effect of cluttering ~ a bit, this could be limited to something around 5 copies.

Let's see what the community thinks before PR.

[mcornella]

We could just use interactive mv to move the zshrc file, which asks the user before overwritting the destination file.

[ncanceill]

I like this solution with mv -i. Anyone care to submit a PR?

[apjanke]

I like this idea, but think the timestamped/countered copies might be better than mv -i. A user who hits the interactive mv -i prompt might not know the significance of what it's asking until too late. (E.g. a new user might not know that OMZ moves and replaces .zshrc, and that the pre-oh-my-zsh one is their original, and the effect depends on how many times OMZ has been installed.) And then if you answer no, you have to abort the install, manually back up your .zshrc, and restart the installation.

We probably don't need to worry much about cluttering up ~ with the backup files. Most users won't be installing OMZ many times. And we can use diff to avoid creating redundant copies: IIRC, the new .zshrc created by OMZ's installer is exactly the same each time, so you'd only have multiple backup files where there were significant user-generated changes, which I think you'd want to preserve.

IMHO, avoiding destructive changes to user data should be a high priority, and worth some clutter to make it less likely to happen.

[apjanke]

I went and made a PR for this: #4391.

[leoj3n]

Another option to consider is displaying an error message telling the user to resolve the conflict by hand along the lines of "Move the conflicting filename away and try again".

Either way, the user is either going to have to deal with the fact that there are multiple backups when uninstalling, or they will have to deal with the conflict upfront. I think dealing with the conflict up front is less confusing.

[mcornella]

I pulled @apjanke's solution in #5169, which is 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.