Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setup.sh: backups, documentation, file organization, errors #135

Open
CouldBeThis opened this issue Feb 19, 2023 · 0 comments
Open

setup.sh: backups, documentation, file organization, errors #135

CouldBeThis opened this issue Feb 19, 2023 · 0 comments

Comments

@CouldBeThis
Copy link

Hello, cool project!

After installing this, I went into ~/.config/rofi and discovered that it was totally over written.

Since I figured it was all hosed, I did some experiments. I put a file in the directory and reran the script; would it get overwritten? Yes. But this time I did finally notice the output [*] Creating a backup of your rofi configs.... Where could they be?

Finally I went to investigate setup.sh. In there I discovered the location of the backup: ${ROFI_DIR}.${USER}. Then I had a second little heart attack as I realized that potentially a backup of my original directory had been created, but now I had overwritten it. Luckily it seems that a second running of the script creates the directory ~/.config/rofi-myusername/rofi and puts the contents of ~/.config/rofi in there, which tbh confuses me. I got a bit sidetracked with this, see section below.

I do not know if it is really necessary to install this way. Seems a little drastic. After recovering my original files, I just added the new directories created by setup.sh to ~/.config/rofi. In my case there were no filename conflicts. I did not copy over the file config.rasi. Nevertheless everything in ~/rofi/scripts looks like it moreorless works. I haven't proceeded with anything beyond just opening a couple of those from the terminal so maybe they would be broken in some other way that I didn't notice.

I looked in the config.rasi and I see there is a bunch of stuff in it, looks like it would be doing something. So assuming it is required, have you considered

  1. keep a separate file, which depending on how it works
  • IIRC there a way to specify which .rasi file gets used when you call rofi
  • Or, use@import to include it in ~/.config/rofi/config.rasi

While it could work to throw everything together, now that I added back my original files it's all mixed up together, half is mine and half is yours.

  1. It might be an idea, in general, to move all the stuff related to this project into a subdir to keep it all together. I don't know if there is some kind of convention for this with rofi customization.

In any case, if a backup is created, I would suggest

  1. Add prominent information in the documentation to explain this.

  2. Indicate the location of the backups in both the docs and the terminal output.

backup creation

I experimented a bit and found that if you run it again (this is the 3rd time in a row) it will output

[*] Installing fonts... 
[*] Updating font cache...
 
[*] Creating a backup of your rofi configs... 
mv: cannot move '/home/myusername/.config/rofi' to '/home/myusername/.config/rofi.un/rofi': Directory not empty
[*] Installing rofi configs... 
[*] Successfully Installed.

Scrolling up in the temrinal, I confirmed that the line beginning mv: (or anything resembling it) did not appear on 2nd running. Presumably because it somehow created ~/.rofi/rofi.

  1. The script should stop in case of such an error.

This time though, ~/.config/rofi actually looked a little closer to what I would have expected in the first place. It left the contents of the current directory and added the new files. Although it does then overwrite config.rasi (and presumably any other file with name conflict) without backing it up. It does not fully overwrite directories that already exist, just adds your files.

  1. This whole backup dir thing could be solved by appending something like $(date +"%y%m%d-%H%M%S") (outputs eg 230209-1012) to the backup directory name. Could just replace ${USER} with this.

It may seem to be a very unusual situation and usecase to run the installer 3 times. However, if the project matures, users may with to upgrade. If I wanted to upgrade, I might just re-run the installer. If prior backups were still present, this would overwrite my files without backup.


Just some feedback, do with it what you will.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant