Coder Social home page Coder Social logo

thoughtbot / rcm Goto Github PK

View Code? Open in Web Editor NEW
3.1K 72.0 133.0 2.06 MB

rc file (dotfile) management

Home Page: https://thoughtbot.github.io/rcm/rcm.7.html

License: BSD 3-Clause "New" or "Revised" License

Shell 20.43% Perl 63.14% Makefile 3.77% M4 0.99% Raku 8.25% Python 3.41%
unix

rcm's Introduction

rcm

This is a management suite for dotfiles. See the tutorial to get started quickly.

It assumes that you have a separate dotfiles directory, or are interested in creating one.

The programs provided are rcup(1), mkrc(1), rcdn(1), and lsrc(1). They are explained in the tutorial and configured using rcrc(5).

Installation

Alpine Linux:

sudo apk add rcm

Arch Linux:

https://aur.archlinux.org/packages/rcm/

Debian (see further down for Ubuntu):

sudo wget -q https://apt.tabfugni.cc/thoughtbot.gpg.key -O /etc/apt/trusted.gpg.d/thoughtbot.gpg
echo "deb https://apt.tabfugni.cc/debian/ stable main" | sudo tee /etc/apt/sources.list.d/thoughtbot.list
sudo apt-get update
sudo apt-get install rcm

Fedora:

sudo dnf install rcm

FreeBSD:

sudo pkg install rcm

Gentoo:

emerge app-admin/rcm

Korora:

64-bit Korora 23:

sudo dnf copr enable seeitcoming/rcm fedora-23-x86_64
sudo dnf install rcm

Korora is similar to Fedora but with an additional version and architecture specification. Replace fedora-23-x86_64 as appropriate.

macOS with Homebrew:

brew install rcm

macOS with MacPorts:

port install rcm

OpenBSD:

doas pkg_add rcm

openSUSE/RHEL/CentOS: instructions

Ubuntu (19.04 or later):

sudo apt update
sudo apt install rcm

Ubuntu (12.04, 14.04, 16.04, 18.04, or 18.10):

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:martin-frost/thoughtbot-rcm
sudo apt-get update
sudo apt-get install rcm

Void Linux:

sudo xbps-install -S rcm

Elsewhere:

This uses the standard GNU autotools, so it's the normal dance:

curl -LO https://thoughtbot.github.io/rcm/dist/rcm-1.3.4.tar.gz &&

# Use sha256sum with GNU coreutils, sha256 on BSD and macOS
sha=$(sha256sum rcm-1.3.4.tar.gz | cut -f1 -d' ') &&
[ "$sha" = "9b11ae37449cf4d234ec6d1348479bfed3253daba11f7e9e774059865b66c24a" ] &&

tar -xvf rcm-1.3.4.tar.gz &&
cd rcm-1.3.4 &&

./configure &&
make &&
sudo make install

For more, see INSTALL.

Programs

  • rcup(1) is the main program. It is used to install and update dotfiles, with support for tags, host-specific files, and multiple source directories.
  • rcdn(1) is the opposite of rcup(1).
  • mkrc(1) is for introducing a dotfile into your dotfiles directory, with support for tags and multiple source directories.
  • lsrc(1) shows you all your dotfiles and where they would be symlinked to. It is used by rcup(1) but is provided for your own use, too.

Support

Pull requests welcome; see CONTRIBUTING.md.

License

Copyright 2013 Mike Burns. BSD license. Copyright 2014 thoughtbot. BSD license.

About thoughtbot

thoughtbot

This repo is maintained and funded by thoughtbot, inc. The names and logos for thoughtbot are trademarks of thoughtbot, inc.

We love open source software! See our other projects. We are available for hire.

rcm's People

Contributors

alanyee avatar alexg0 avatar caleb avatar develop7 avatar docwhat avatar formigarafa avatar frost avatar github-actions[bot] avatar gurdiga avatar hugelgupf avatar jkniiv avatar kajisha avatar lbschenkel avatar mat-m avatar mhoran avatar mike-burns avatar mxie avatar nicknovitski avatar ratijas avatar raviqqe avatar rmeritz avatar robertopedroso avatar srstevenson avatar stefannibrasil avatar stephengroat avatar tabfugnic avatar teoljungberg avatar thelonelyghost avatar tysongach avatar zachlatta avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rcm's Issues

Executable hooks aren't run

If a hook has a mode of 750 or even 700, it isn't run, even though it's executable by the user's standard. I've seen umask 077 used in other places, so I wouldn't consider this particularly esoteric.

I read through #9 and saw that find -executable was dropped for not being POSIX. However, find -perm +111 doesn't exhibit the same behaviour. I had a look at other find options, and find -perm /a+x seems to be synonymous with -executable, but isn't POSIX either.

I'd suggest reverting to the loop in 9187047. It might be longer, but at least it's correct.

Option -S for directory symlink is -N in usage and documentation

It appears that the -S option is inconsistently documented. It is -N in some places and not documented at all in others.

From lsrc

Usage: lsrc [-FVqvh] [-I EXCL_PAT] [-x EXCL_PAT] [-N EXCL_PAT ] [-t TAG] [-d DOT_DIR]

and from man 1 lsrc

SYNOPSIS
     lsrc [-Fvq] [-d dir] [-I excl_pat] [-t tag] [-x excl_pat] [-N excl_pat] [files ...]

and also

-S excl_pat  symlink the directories that match the given pattern. See EXCLUDE PATTERN for more details. This option can be repeated. You
                  may need to quote the pattern to prevent the shell from swallowing the glob.

It is not documented in usage for mkrc Usage: mkrc [-hvqo] [-t TAG] [-d DIR] FILES ... despite having been implemented as in mkrc -S test1.

Handle non-dotted dotfiles

This is probably easier to explain by example:

Say I have ~/Library/LaunchAgents/my.plist that I want to bless.
I run mkrc Library/LaunchAgents/my.plist. If I run lsrc, I see that rcup would create a link in ~/.Library/..., which is obviously not what I want.

If you don't like the idea, at least consider throwing an error when running mkrc on a non-dotted file, since rcup cant't handle it.

rcup fails to link some files when multiple directories are specified

I'm trying to switch my dotfiles over to using rcm and building on the thoughtbot dotfiles. My repository containst mostly .local overrides to the thoughtbot dotfiles.

I'm running into a problem when using rcm in this way and have a very simple reproduction below:

% mkdir rc-me
% mkdir rc-them
% touch rc-me/foo.local
% touch rc-them/foo
% touch rc-them/bar
% rcup -d $HOME/rc-me -d $HOME/rc-them -v
'/Users/derek/rc-me/foo.local' -> '/Users/derek/.foo.local'
'/Users/derek/rc-them/bar' -> '/Users/derek/.bar'

Notice that files from both directories were symlinked, but for some reason rc-them/foo was skipped. This seems to be the pattern in my problems with my actual dotfiles. If the .local version is already symlinked, rcup won't symlink the non-.local version.

Using .dotfiles/rcrc

When I first clone my .dotfiles repo, I have to symlink .rcrc to .dotfiles/rcrc manually. That's a bit of a hassle, why not look at .dotfiles/rcrc (or, well, $DOTFILES_DIR/rcrc) when .rcrc does not exist?

Edit: I suppose the tricky part here is supposed to be the -d option, which is not processed until after rcrc is needed.

"WARNING: 'aclocal-1.13' is missing on your system."

I get this error when building master. ./configure then make. The problem is that I have aclocal-1.14 but the configure script hardcodes 1.13. I had to change the configure script, line 1707. It worked after that.

Handling sub-dotfiles

rcm currently skips dot files in the dotfiles directory. Normally this is what you want.

dotfiles/zshrc -> ~/.zshrc
dotfiles/config/screenrc -> ~/.config/screenrc
dotfiles/.gitignore -> noop

Unfortunately, there is one use-case where this falls down: ZSH.

ZSH lets you export ZDOTDIR to define where its startup files are searched for. This is great because I can get a ton of ~/.z* files out of my home directory and into ~/.config/zsh.

Unfortunately, this requires awkward naming like ~/.config/zsh/.zshrc. This is most certainly a failing of ZSH and not rcm, but I seem stuck with it and therefore would like some mechanism to get rcm to do the following:

dotfiles/config/zsh/.zshrc -> ~/.config/zsh/.zshrc
dotfiles/config/zsh/.zprofile -> ~/.config/zsh/.zprofile

I'm not sure how best to do this. Some options:

  1. Any nested dotfiles (dotfiles/foo/.bar) should be linked like normal files while still ignoring any top-level dotfiles (dotfiles/.git).
  2. Allow some rcrc option to tell rcm specifically about odd files like this
  3. Add/Use some max-depth option to symlink (in this case) ~/.config/zsh as a whole directory.

I don't mind PRing this myself, but would like some input on what might be a good solution before I start.

configure file missing

All installation documents indicate that the configure script is included, including the last paragraph of INSTALL that says you should only need to regenerate the configure script if you want to use a different version of autoconf. However, the configure script was removed in 3cc63e0 because it is a generated file.

Either add the file back or update docs to include steps to build configure.

mkrc without hooks

I don't see any reason for mkrc to run hooks and would prefer it didn't. I'd also be OK with adding -k/-K support so I can disable them myself.

lsrctag

A program to list all possible tags.

rcm commands don't show usage messages when given bad arguments

$ rcup --version
/usr/local/bin/rcup: illegal option -- -
/usr/local/bin/rcup: illegal option -- e
/usr/local/bin/rcup: illegal option -- r
/usr/local/bin/rcup: illegal option -- s
/usr/local/bin/rcup: illegal option -- o
/usr/local/bin/rcup: illegal option -- n
identical /Users/georgebrocklehurst/.bash_hosts
…

SYMLINK_DIRS and tags

~% lsrc -FS zsh | grep zsh
/home/mike/.zsh:/home/mike/.dotfiles/zsh:@
/home/mike/.zsh/configs/debian:/home/mike/.dotfiles/tag-debian/zsh/configs/debian:@
# ....

Looks like it symlinks anything under a tag, regardless of SYMLINK_DIRS.

EXCLUDES not working as expected

I have the following files in my ~/.dotfiles directory:

config/systemd/user
config/xfce4
systemd

I only want to exclude config/systemd/*, so I've tried the following:

EXCLUDES="config/systemd" 
$ lsrc -v 
/home/pablo/.config/systemd/user/default.target:/home/pablo/.dotfiles/config/systemd/user/default.target
/home/pablo/.config/systemd/user/[email protected]:/home/pablo/.dotfiles/config/systemd/user/[email protected]
/home/pablo/.config/systemd/user/empty.target:/home/pablo/.dotfiles/config/systemd/user/empty.target
/home/pablo/.config/systemd/user/[email protected]:/home/pablo/.dotfiles/config/systemd/user/[email protected]
/home/pablo/.config/systemd/user/[email protected]:/home/pablo/.dotfiles/config/systemd/user/[email protected]
[ ... a lot of output removed .... ]
/home/pablo/.systemd:/home/pablo/.dotfiles/systemd
EXCLUDES="systemd" # or "*:systemd"
$ lsrc -v 
/home/pablo/.config/xfce4/......
[ ... a lot of output removed .... ]

Following the instructions for the lsrc man page, I followed the idea of the thoughbot-dotfiles example:

EXCLUDES="config:systemd" # or "config:*systemd*"
$ lsrc -v 
/home/pablo/.config/systemd/user/default.target:/home/pablo/.dotfiles/config/systemd/user/default.target
/home/pablo/.config/systemd/user/[email protected]:/home/pablo/.dotfiles/config/systemd/user/[email protected]
/home/pablo/.config/systemd/user/empty.target:/home/pablo/.dotfiles/config/systemd/user/empty.target
/home/pablo/.config/systemd/user/[email protected]:/home/pablo/.dotfiles/config/systemd/user/[email protected]
/home/pablo/.config/systemd/user/[email protected]:/home/pablo/.dotfiles/config/systemd/user/[email protected]
[ ... a lot of output removed .... ]
/home/pablo/.systemd:/home/pablo/.dotfiles/systemd

Same thing... am I misunderstanding how it works?

Ability to package rcm within the dotfiles repository itself

Most people with existing dotfile repos handle file installation via a home-rolled make, rake, or shell script. While I love the idea of using rcm as a robust OTS framework, I don't look forward to having the additional step of installing rcm itself, especially on servers where I don't have root access.

It's clear from #68 that it's a good design decision to reduce the number of dependencies within rcm. Wouldn't it be nice if we could also remove the dependency of installing rcm itself? rcm still seems pretty portable (assuming it doesn't get completely re-written in c). Is there any reason we can't bundle it -- or at a minimum, just rcup -- inside the dotfiles repo the same way people vendor ruby gems with bundle package?

Credit authors

Currently the only person who seems to get any credit for this tool is myself, but this is clearly wrong.

We should list contributors in the rcm(7) manpage. As of right now this is Pablo Olmos de Aguilera Corradini (PaBLoX-CL), Jordan Eldredge (captbaritone), George Brocklehurst (georgebrock), Roberto Pedroso (robertopedroso), Patrick Brisbin (pbrisbin), and Dan Croak (croaky).

Part of the contributing guidelines should mention adding yourself to this list of contributors.

rcdn -K -k

rcdn(1) has all the code needed to support -k and -K but getopts forbids it. Solution: add Kk to the getopts arg.

How to manage external libraries like git submodules?

I have some of my dotfiles in submodules (like zsh-users completion), since they are supposed to be managed by git, I think that rcm should only control only the linking.

Use case:

I want to add http://github.com/seebi/dircolors-solarized as a submodule and make it live on ~/.dircolors.

  • To manage it that way I'll have to add it trough git submodule in the dotfiles repo.
  • It would be easier if rcup only made a link from ~/.dircolors -> ~/.dotfiles/dircolors instead of linking every file inside the folder.

I was thinking that .rcrc would be the best place to add it like:

EXCLUDES="readme"
MODULES="dircolors"

As a workaround now I'm adding dircolors to EXCLUDES and linking it by hand.

Is it possible? I could try to implement it myself, but I'm a bit lost in how to do it (or where to start).

Allow overriding of SYMLINK_DIRS

Every option should have an opposite. -S does not have an opposite.

Introduce a -s that can force a return to normalcy that overrides a prior -S.

This is especially useful for making mkrc -s work smoothly.

Support dotted files in a subdirectory of dotfiles dir

I didn't find a way how to handle dotted files such as .hgignore inside a subdirectory hg [maps to ~/.hg]) of dotfiles directory. It's not a ignore file for directory ~/.dotfiles/hg, it's actual config file, I need it.
In Mercurial global config (~/.hgrc) I have following lines:

[ui]
ignore = ~/.hg/.hgignore

There is no precise definition how should I name global ignore file, I named it equally to a repository level name. In this particular case I can easily rename it. But what should I do if I couldn't?

Prefer tagged files over non-meta-files

So if you have:

.dotfiles/tag-freebsd/kshrc
.dotfiles/kshrc

An lsrc -t freebsd would only list the kshrc in .dotfiles/tag-freebsd/kshrc.

What do people think? This is a breaking change, and I don't have feelings on it either way.

How does this compare to ...

Add notes to the README on how this compares to Homesick, Homeshick, GNU Stow, and copying install.sh around.

tag-specific pre-up and post-up hooks

I'd like a way to add a hooks directory to tags, so that tags can have their own pre-up and post-up hooks. Here's a use case:
I have a vim tag that installs my .vimrc file. I'd like a post-up hook that creates the .vim directory if it doesn't exist and automatically clones vundle so that I can install bundles listed in my .vimrc next time I start vim. I don't want a general post-up hook because only machines using the tag vim should run this particular part of the script.
Similarly, I have a zsh tag. I want all machines using zsh to run a post-up hook that clones and installs oh-my-zsh, if it doesn't exist.

Request: Test parameter availability.

Under OpenBSD commands must be executed with the '-q' option to avoid errors. Neither rm, ln, cp and mv accept the '-v' option.
I only use git at home... I'll learn how to 'pull requests' soon.
Here is the request. I've used format-patch:

From 60bce29325c9e2f2de67483f41e1252a3a0fd125 Mon Sep 17 00:00:00 2001
From: The Linux Kitten <kitten@openbsdbox>
Date: Sun, 9 Mar 2014 02:59:20 +0100
Subject: [PATCH] (OpenBSD) Test parameter availability.

---
 share/rcm.sh.in | 29 +++++++++++++++++------------
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/share/rcm.sh.in b/share/rcm.sh.in
index bccc0a9..d679383 100644
--- a/share/rcm.sh.in
+++ b/share/rcm.sh.in
@@ -18,6 +18,11 @@ INSTALL=rcup
 ROOT_DIR="$HOME"
 HOSTNAME="$(hostname | sed -e 's/\..*//')"

+if ! $LN -v 2>/dev/null ; then LN_V=$LN ; else LN_V="$LN -v" ; fi
+if ! $CP -v 2>/dev/null ; then CP_V=$CP ; else LN_V="$CP -v" ; fi
+if ! $RM -v 2>/dev/null ; then RM_V=$RM ; else LN_V="$RM -v" ; fi
+if ! $MV -v 2>/dev/null ; then MV_V=$MV ; else LN_V="$MV -v" ; fi
+
 unset CDPATH

 echo_n() {
@@ -61,28 +66,28 @@ handle_common_flags() {
     DEBUG=echo_stderr
     VERBOSE=echo
     PRINT=echo
-    MV="$MV -v"
-    RM="$RM -v"
-    LN="$LN -v"
-    CP="$CP -v"
+    MV="$MV_V"
+    RM="$RM_V"
+    LN="$LN_V"
+    CP="$CP_V"
     INSTALL="$INSTALL -vv"
   elif [ $verbosity -eq 1 ]; then
     DEBUG=:
     VERBOSE=echo
     PRINT=echo
-    MV="$MV -v"
-    RM="$RM -v"
-    LN="$LN -v"
-    CP="$CP -v"
+    MV="$MV_V"
+    RM="$RM_V"
+    LN="$LN_V"
+    CP="$CP_V"
     INSTALL="$INSTALL -v"
   elif [ $verbosity -eq 0 ]; then
     DEBUG=:
     VERBOSE=:
     PRINT=echo
-    MV="$MV -v"
-    RM="$RM -v"
-    LN="$LN -v"
-    CP="$CP -v"
+    MV="$MV_V"
+    RM="$RM_V"
+    LN="$LN_V"
+    CP="$CP_V"
   else
     DEBUG=:
     VERBOSE=:
-- 
1.8.3.3

Migrations, being specific about files, and manifests

Consider a world where lsrc(1) worked very differently. Instead of recurring through a directory tree, mimicking it onto a base directory, it could instead have a MANIFEST of rules. Here is a quick example MANIFEST:

S zprezto ~/.zprezto           # 1
X ~/.vim/configs/vundle        # 2
I README.md                    # 3
C tag-ssh/(ssh/config) ~/.\1   # 4

# Default MANIFEST:

R tag-$TAG/(.*(/))             # 5
S tag-$TAG/(.*(.)) ~/.\1       # 6
R host-$HOST/(.*(/))           # 7
S host-$HOST/(.*(.)) ~/.\1     # 8
R (.*(/))                      # 9
S (.*(.)) ~/.\1                # 10
I hooks                        # 11

The ideas I'm trying to express:

  1. Symlink the zprezto directory into place instead of recurring on its files.
  2. Delete the ~/.vim/configs/vundle file, if found. This statement needs work: what if another dotfiles dir provides the original file? what if, many months after this line went in, something changed? This idea happened becaus I moved the file to ~/.vim/configs/pre/vundle. What I'm trying to express here is a migration.
  3. Ignore README.md.
  4. Copy the ssh/config file to ~/.ssh/config instead of symlinking it. The ssh/config file is under the tag-ssh directory. What if we don't want the ssh tag in this run?
  5. For each tag that the user wants, substitute $TAG with that tag, then find all directories under there and recur on those.
  6. For each tag that the user wants, substitute $TAG with that tag, then find all files under there. Symlink them. This and (5) are always paired together and are ugly. Plus it seems annoying to implement this.
  7. Same as (5) but for $HOST.
  8. Same as (6) but for $HOST.
  9. Same as (5) but for the dotfiles dir root.
  10. Same as (6) but for the dotfiles dir root.
  11. Ignore the hooks directory.

With more to consider:

  • The default MANIFEST happens for dotfiles dirs that do not have a MANIFEST file. Keep the barrier to entry low.
  • This could get rid of hacks like UNDOTTED, SYMLINK_DIRS, COPY_ALWAYS.
  • The MANIFEST should be able to be augmented by a local MANIFEST.
  • I would like a future where only files for a specific tag are listed, excluding e.g. (10).
  • The idea is that anything that the first match wins, so it should get more general as you read down. Just how hard will this be to implement? I'm worried about (1) and (10) combining.
  • The idea is that S is a rewrite rule using a regexp.

Is this idea worth considering? Is it too far against the ethos of the project?

Two-way sync

Problem: want to commit my weechat, gnupg, ssh files to my repo, but those files shouldn't be symlinks.

I think the solution is to sync the files back to my repo automatically. No idea what the UI for this should look like.

Considerations:

  • Tagged/host-specific files.
  • Multiple dotfiles dirs.

rcup: add option for calling diff program on a conflict

I update my dotfiles with rcup and it gives me:

overwrite /root/.oh-my-fish/custom/plugins/example/example.fish? [ynaq]

It would be nice to have one another option d for calling diff program diff, for example, or vimdiff depending on a line in config file (default value):

DIFF_PROGRAM="diff $SRC $DST"

To make it clear I propose to change question to:

overwrite $FILE? (y/n/d/a/q/? - show all options) [y]:

? should give brief explanations of options. y is default.

This is somehow related with #13, but it works on concrete file, not for all files.

user-[user]@[hostname] dir for user specific files

I can handle specific configs for PCs with host... dir. I wish to have user-[user]@[hostname] directory for user files. Why do I need this? Well, I'm using rcm as a normal user and as a root and I cannot use mkrc -o ~/.rcrc recipe as root user don't uses GUI applications (and corresponding tags of course).

C version of lsrc

I saw some talk here about making a C version of lsrc. So I went ahead and wrote it.

Here's the branch:

https://github.com/caleb/rcm/tree/lsrcc

It's not yet integrated with the auto* tools, so you'll have to clang lsrc.c it manually.

All of the features of the shell version should be included in the C version, and it's significantly faster (0.02 seconds vs 16 seconds with my admittedly big dotfiles directory).

This first version is basically a port of the APIs from the shell version to C. In the future I would be interested in cleaning up those APIs to maybe remove shell-isms, but to keep parity I decided to port the functions directly as much as possible.

I've been using this for a couple weeks now with no problems. It handles spaces, and files with asterisks in their names, etc. I used only POSIX C99 (I believe!), and have tested a slightly older version on NetBSD, FreeBSD, OpenBSD, Ubuntu, and OS X.

I would definitely do testing on the final version on those platforms if you're interested in merging.

Is this something that you'd be interested in including upstream if I finish the build system and testing?

global, host, and tag ordering not working as expected.

The ordering of which file is used seems off.

It seems like rcup creates symlinks based on the first found in this ordered list:

  1. The global (root)
  2. The host
  3. The tag

I expected it to be this order:

  1. The host
  2. The tag
  3. The global

This is because I expect it to go from specific (host) to the general (global).

Is this by design? Or should this be changed?

Ciao!

Thoughts about mkrc with absolute/full paths

Ok, this basically started since I tried to run:

~ ❯❯❯ mkrc -v /tmp/t/.foo
Moving...
'/tmp/t/.foo' -> '/home/pablo/.dotfiles//tmp/t/.foo'
Linking...

This came up when I tried to add the feature in 2e283083e6, though it's not something that was introduced there (considering the bugfixes).

So, here's the thing: what's the point in using mkrc in a file from the root outside the home directory? I don't think so it actually makes sense. The only use case I can came up would be trying to "backup" global configuration files (/etc/X11/xorg.conf.d/something.conf), but it's also a PITA since you would need special privileges.

Having a path starting with / it's not enough,since /home/user/.vimrc it's actually valid and it's run correctly through mkrc.

So, wouldn't be better add a handling to cover those edge cases? Maybe we could add a condition inside the case statement to see if the full path includes $HOME and if it's not, bail out more gracefully.

diffrc

A program to see what would happen if you ran rcup, as a diff. Different from rcup -n in that it shows a diff instead of list of files it would symlink/copy.

Release a new version.

thoughtbot/dotfiles relies on the post-hook running to setup vundle. The bug preventing this is fixed but not released -- I'd like to release a new version before resorting to documenting the -k workaround in dotfiles' README.

Exclude paths

Given:

~% ls dottest/**/*(.)
dottest/testdir/barfile  dottest/testdir/foodir/barfile

Expected:

~% lsrc -d dottest -x testdir/foodir        
/home/mike/.testdir/barfile:/home/mike/dottest/testdir/barfile

Reality:

~% lsrc -d dottest -x testdir/foodir
/home/mike/.testdir/barfile:/home/mike/dottest/testdir/barfile
/home/mike/.testdir/foodir/barfile:/home/mike/dottest/testdir/foodir/barfile

The fix: in handle_file, when calling is_excluded, pass $dotfiles_subdir/$file instead of just $file.

lsrc with multiple -d options

$ mkdir {foo,bar}
$ touch foo/zshrc bar/vimrc
$ lsrc -d foo
/home/patrick/.zshrc:/home/patrick/foo/zshrc
$ lsrc -d bar
/home/patrick/.vimrc:/home/patrick/bar/vimrc

Expected

$ lsrc -d foo -d bar
/home/patrick/.zshrc:/home/patrick/foo/zshrc
/home/patrick/.vimrc:/home/patrick/bar/vimrc

Actual

$ lsrc -d foo -d bar
/home/patrick/.zshrc:/home/patrick/foo/zshrc

Separate repository- and host-specific rcrc configuration options

It seems a bit weird to have both in the same file, particularly with EXCLUDES vs TAGS.

I'm not quite sure how would be best to handle this. .rcignore would be a nice idea, but probably not that easy to implement and only handles EXCLUDES.

Alternatively, perhaps $dotfiles/.rcrc might be better, since it's more generic and still fits in with the idea of ignoring dotfiles.

Currently I'm working around this with an idea borrowed from thoughtbot/dotfiles:

EXCLUDES="Brewfile launchagents"
[[ -e ~/.rcrc.local ]] && source ~/.rcrc.local

Where .rcrc.local is a host-specific file. I'm not too fond of throwing .local files everywhere though. I might try it the other way around (i.e. .system instead).

Ubuntu PPA

It would be great if there was an Ubuntu PPA to easily keep rcm up to date. Otherwise, knowing about new releases and installing .deb files is a very manual process, and likely to leave out-of-date versions around. I think this is especially important for a project like rcm, since by definition its users will have multiple machines they maintain (or they wouldn't be using rcm in the first place).

Add .rcmignore

The EXCLUDES variable in rcrc is great, but feels limited. In my case, I would love to be able to set exclude patterns on a tag by tag basis. It feels like a good solution to this would be to have the ability to define an .rcmignore file that works much like .gitignore.

Potential for a rewrite PR

This weekend I spent some time scratching an itch.

Every time I try to work on rcm to either improve some actual functionality, add tests, or just fixup the codebase a bit, I find myself unable to gain any traction as a bit of refactor over here leads to a bit of refactor over there -- and I know myself that when a PR has a messy diff due to variable renames or function relocation it's difficult to review and may never be merged -- if it ain't broke, don't fix it.

That said, I really want to fix it. The idea and functionality behind rcm is genius and epic-ly useful, but I find the codebase difficult to follow or extend, the build process convoluted and inconvenient, and adding tests hit or miss so far.

So I rewrote rcm from scratch as rcm2. It began as an experiment in seeing how small I could make lsrc/rcup by sharing functionality differently, then snowballed into what I think is full feature-parity with current rcm but in cleaner, smaller, well-tested scripts.

The rcm2 README has more details, but here are a few of the improvements:

  • It's ~250 lines less than rcm in total (according to sloccount bin share) and I think it's very clear, readable shell.
  • The individual executables are on the order of tens of lines each with almost all of the heavy-lifting now in rcm.sh, which is almost entirely covered by tests. This could also be easily taken further.
  • I ditched all the auto* stuff. It rubs me the wrong way for installing shell scripts. I'm hopeful that seeing rcm2's 20 line Makefile might convince you that simpler can be better.

I think these things are valuable and would like to put in the effort to bring them to rcm -- assuming there is no loss in functionality.

So:

  • Would you be interested in a rewrite-ish PR at all?
  • Might there be a way to transition these fixes from rcm2 to rcm in smaller parts, or does it need to come over whole-hog?

Suggestions and discussion very much welcome.

Prints an error when no hooks directory exists

~% mkrc -S .zappos 
Moving...
‘.zappos’ -> ‘/home/mike/.dotfiles/zappos’
Linking...
find: `/home/mike/.dotfiles/hooks/pre-up': No such file or directory
‘/home/mike/.zappos/high-tops’ -> ‘/home/mike/.dotfiles/zappos/high-tops’
find: `/home/mike/.dotfiles/hooks/post-up': No such file or directory

This happened in #9.

Build a pkgng package

For FreeBSD. The tricky bit is that this requires a slightly modified tarball, which currently can only be made using pkg create.

Generated executables are not

After running the autogen.sh, configure, make incantation, I find that the generated executables under ./bin are not executable.

% ls -l bin
total 68
-rwxr-xr-x 1 patrick users  8119 Mar 31 17:43 lsrc.in*
-rw-r--r-- 1 patrick users 15038 Mar 31 17:43 Makefile
-rw-r--r-- 1 patrick users    39 Mar  6 17:26 Makefile.am
-rw-r--r-- 1 patrick users 14731 Mar 31 17:43 Makefile.in
-rwxr-xr-x 1 patrick users  1707 Mar 31 17:43 mkrc.in*
-rwxr-xr-x 1 patrick users  2261 Mar 31 17:43 rcdn.in*
-rwxr-xr-x 1 patrick users  3577 Mar 31 17:43 rcup.in*
-rw-r--r-- 1 patrick users  8881 Mar  3 12:10 tags
% make
...
% ls -l bin
total 88
-rw-r--r-- 1 patrick users  8119 Mar 31 17:50 lsrc
-rwxr-xr-x 1 patrick users  8119 Mar 31 17:43 lsrc.in*
-rw-r--r-- 1 patrick users 15038 Mar 31 17:43 Makefile
-rw-r--r-- 1 patrick users    39 Mar  6 17:26 Makefile.am
-rw-r--r-- 1 patrick users 14731 Mar 31 17:43 Makefile.in
-rw-r--r-- 1 patrick users  1707 Mar 31 17:50 mkrc
-rwxr-xr-x 1 patrick users  1707 Mar 31 17:43 mkrc.in*
-rw-r--r-- 1 patrick users  2261 Mar 31 17:50 rcdn
-rwxr-xr-x 1 patrick users  2261 Mar 31 17:43 rcdn.in*
-rw-r--r-- 1 patrick users  3577 Mar 31 17:50 rcup
-rwxr-xr-x 1 patrick users  3577 Mar 31 17:43 rcup.in*
-rw-r--r-- 1 patrick users  8881 Mar  3 12:10 tags

This breaks the test suite branch because the altered $PATH does not find them.

Looking at #72, I expected this to be because they were set as _DATA, not _SCRIPTS (the reverse of that issue), but that's not the case.

My installation seems to work, so permissions are probably set correctly when make install actually fires -- but the test suite requires (at least at this point) that the local files be executable too.

PGP signed configuration files

The craziest of crazy ideas: if the repo contains a PGP signature, it will be verified before sync'ing the config files.

Relatedly crazy idea: check the signature of the .rcrc file.

Dry run option

I think that it would be helpful if rcup, rcdn and maybe mkrc accepted a -n option, which doesn't actually move any files, in a similar way to rsync and git clean.

I have a different layout in my dotfiles directory current, so I'd like to be able to see what would happen if I ran some commands. I've been using lsrc, but I'm not sure if it's the same as a hypothetical rcup -n, since it is a different command.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.