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

Add support to execute .homeshickrc bash script #164

Open
FlorianFranzen opened this issue Aug 12, 2017 · 6 comments
Open

Add support to execute .homeshickrc bash script #164

FlorianFranzen opened this issue Aug 12, 2017 · 6 comments

Comments

@FlorianFranzen
Copy link

FlorianFranzen commented Aug 12, 2017

From the homesick readme:

If you need to add further configuration steps you can add these in a file called '.homesickrc' in the root of a castle. Once you've cloned a castle with a .homesickrc run the configuration with: homesick rc CASTLE
The contents of the .homesickrc file must be valid Ruby code as the file will be executed with Ruby's eval construct. The .homesickrc is also passed the current homesick object during its execution and this is available within the .homesickrc file as the 'self' variable. As the rc operation can be destructive the command normally asks for confirmation before proceeding. You can bypass this by passing the '--force' option, for example homesick rc --force CASTLE.

Would there be any interest to add the same thing to homeshick, in form of a bash script named .homeshickrc at the root of a castle?

@FlorianFranzen FlorianFranzen changed the title Adsshomesickrc Add support to execute .homeshickrc bash script Aug 12, 2017
@andsens
Copy link
Owner

andsens commented Aug 13, 2017

My initial reaction would be, why?
As of right now, the simplicity of homeshick contributes to it being bug-free and stable. Adding new features always brings with it instability and bugs, so there need to be very good reasons for adding this.
To quote the contribution guidelines:

The PR should clearly describe what problem the change fixes. A feature addition with no justification and use-case will be rejected.

So what's the use-case(s)? :-)

@FlorianFranzen
Copy link
Author

I think it would be nice to allow castles to contain code that can easily be run without having to link that code into a folder in your path first or needing to know where homeschick saves your repos, especially for code that only needs to be run on setup or other similar events.

In the end running homeshick rc dotfiles install instead of ~/.homeshick/repos/dotfiles/.homeshickrc install really only saves you a bit of typing.

@kamazee
Copy link

kamazee commented Apr 5, 2018

The use case for running arbitrary code I have in mind is the following.

I've got several castles (one with my personal settings that I'm used to and another with just work-related stuff that I don't need at home) with ssh aliases and git configuration. ssh-aliases are just files in ~/.ssh/config.d; however, in order for them to be processed, ~/.ssh/config has to contain Include config.d/* or even a file name instead of the wildcard. Both castles add files into ~/.ssh/config.d, and so both have to modify ~/.ssh/config (or, with wildcard, at least one of them has to). Storing ~/.ssh/config in one of the castles makes splitting senseless because it makes one castle unusable without another or requires me to edit ~/.ssh/config manually. So a script that checks whether including file contains a directive for inclusion and adds it if not would solve the issue.

Same goes for .gitconfig; I store pieces of it that are to be included but I have to add inclusions manually; it's even a bit worse than ssh example above because unlike ssh, .gitconfig doesn't allow wildcard inclusions.

@arthurp
Copy link

arthurp commented Apr 1, 2019

I have a similar use case. I would like to run a small script at "link" time which combines some config files. In my case there really isn't a work around since the config format doesn't support any form of "#include" or include directories. One instance of this is older ssh (like that installed on my web hosting) which does not support "include" at all.

For my uses executing the file [castle]/hooks/link from each repo at link time if it exists would be perfect. A similar idea for pull or refresh could also be useful for some applications I expect. The script could just be executed from the root of the castle in the user's normal environment. It wouldn't need anything special.

@filviu
Copy link

filviu commented Mar 31, 2020

I'll add a simple use case I stumbled upon. I track my midnight commander configuration. But one thing that mc does is write all the time to .config/mc/ini some panel position info so the file is never clean.

My solution is to track .config/mc/ini.dist and copy ini.dist -> ini when installing on a new machine. I came here searching for a way to script ini.dist -> ini whenever ini.dist changes.

@jasuarez
Copy link

I have also a similar case where I need to update my .bashrc file to include some files in my dotfiles

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

No branches or pull requests

6 participants