mirrors/dotdrop
1
0
Fork 0
mirror of https://github.com/deadc0de6/dotdrop.git synced 2026-02-12 09:33:30 +00:00
Code Activity

update doc

Browse Source
This commit is contained in:
deadc0de6
2020-11-18 13:56:03 +01:00
parent 541c6310fb
commit 7ff5ca3f85
4 changed files with 32 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/config.md
View File

@@ -77,11 +77,12 @@ On `import` the following rules are applied:
On `install` the following rules are applied: On `install` the following rules are applied:
* if `chmod` is specified in the dotfile, it will be applied to the installed dotfile * if `chmod` is specified in the dotfile, it will be applied to the installed dotfile
* otherwise the permissions of the dotfile in the `dotpath` are applied.
On `update`: On `update`:
* if the permissions of the file in the filesystem differ from the dotfile in the `dotpath` * if the permissions of the file in the filesystem differ from the dotfile in the `dotpath`
then the dotfile entry `chmod` is updated accordingly then the dotfile entry `chmod` is added/updated accordingly
## Symlink dotfiles ## Symlink dotfiles

26
docs/howto/global-config-files.md
View File

@@ -1,26 +0,0 @@
# Manage system dotfiles
Dotdrop doesn't allow to handle file rights and permissions (at least not directly). Every operations (`mkdir`, `cp`, `mv`, `ln`, file creation) are executed with the rights of the user calling dotdrop. The rights of the stored dotfile are mirrored on the deployed dotfile (`chmod` like). It works well for local/user dotfiles but doesn't allow to manage global/system config files (`/etc` or `/var` for example) directly.
Using dotdrop with `sudo` to handle local **and** global dotfiles in the same *session* is a bad idea as the resulting files will all have messed up owners.
It is therefore recommended to have two different config files (and thus two different *dotpath*) for handling these two uses cases:
* one `config.yaml` for the local/user dotfiles (with its dedicated *dotpath*)
* another config file for the global/system dotfiles (with its dedicated *dotpath*)
The default config file (`config.yaml`) is used when installing the user dotfiles as usual
```bash
# default config file is config.yaml
$ ./dotdrop.sh import <some-dotfile>
$ ./dotdrop.sh install
...
```
A different config file (for example `global-config.yaml` and its associated *dotpath*) is used when installing/managing global dotfiles and is to be used with `sudo` or directly by the root user
```bash
# specifying explicitly the config file with the --cfg switch
$ sudo ./dotdrop.sh import --cfg=global-config.yaml <some-dotfile>
$ sudo ./dotdrop.sh install --cfg=global-config.yaml
...
```

2
docs/howto/howto.md
View File

@@ -28,7 +28,7 @@
## Manage system dotfiles ## Manage system dotfiles
[Manage system dotfiles](global-config-files.md) [Manage system dotfiles](system-config-files.md)
## Merge files on install ## Merge files on install

29
docs/howto/system-config-files.md Normal file
View File

@@ -0,0 +1,29 @@
# Manage system dotfiles
Dotdrop doesn't allow to handle file owernership (at least not directly). Every file operations (create/copy file/directory, create symlinks, etc) are executed with the rights of the user calling dotdrop.
Using dotdrop with `sudo` to unprivileged and privileged files in the same *session* is a bad idea as the resulting files will all have messed up owners.
It is therefore recommended to have two different config files (and thus two different *dotpath*)
for handling these two uses cases:
For example:
* one `config-user.yaml` for the local/user dotfiles (with its dedicated *dotpath*, for example `dotfiles-user`)
* one `config-root.yaml` for the system/root dotfiles (with its dedicated *dotpath*, for example `dotfiles-root`)
`config-user.yaml` is used when managing the user's dotfiles
```bash
## user config file is config-user.yaml
$ ./dotdrop.sh import --cfg config-user.yaml <some-dotfile>
$ ./dotdrop.sh install --cfg config-user.yaml
...
```
`config-root.yaml` is used when managing system's dotfiles and is to be used with `sudo` or directly by the root user
```bash
## root config file is config-root.yaml
$ sudo ./dotdrop.sh import --cfg=config-root.yaml <some-dotfile>
$ sudo ./dotdrop.sh install --cfg=config-root.yaml
...
```