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

Modify rc file instead of overwritting #33

Open
dmlemos opened this issue Oct 19, 2019 · 5 comments
Open

Modify rc file instead of overwritting #33

dmlemos opened this issue Oct 19, 2019 · 5 comments

Comments

@dmlemos
Copy link
Contributor

dmlemos commented Oct 19, 2019

My cmus configuration is kept on the rc file (as recommended from cmus team).

The problem is the file gets overwritten upon every install. I think it should be modified instead.

@PhilipTrauner
Copy link
Owner

I'm not entirely sure that I fully understand the issue here. The newly introduced temporary file based approach doesn't wipe the contents of your rc file.
It just replaces the file itself with a temporary file that was previously populated with the contents of your current rc, while appending the cmus_osx specific entry.
Additionally, if the cmus_osx entry is already present, no replacement is taking place.

I implemented it this way, because I deemed atomically replacing the current file to be a better / cleaner approach than reading the contents of a users rc file into a buffer, conditionally appending the cmus_osx specific entry to said buffer, and overriding the rc file with the contents of said buffer.

@dmlemos
Copy link
Contributor Author

dmlemos commented Oct 20, 2019

I think I didn't state the problem clear enough.

My config is symlinked to my dotfiles repository.
Since it uses a temporary file, it basically replaces rc instead of modifying it, which is frustrating.

Additionally, if the cmus_osx entry is already present, no replacement is taking place.

In this case it doesn't do that, and in fact replaces the file every time as mentioned above.

@PhilipTrauner
Copy link
Owner

That would mean, that resolving the symlink would fix this, right?

@dmlemos
Copy link
Contributor Author

dmlemos commented Oct 20, 2019

Yep. I believe so.

@PhilipTrauner
Copy link
Owner

Let's get dmlemos#1 in first, as it already bumps the version and then I'll tackle this.

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

2 participants