mirrors/dotdrop
1
0
Fork 0
mirror of https://github.com/deadc0de6/dotdrop.git synced 2026-02-04 23:14:47 +00:00
Code Activity

Merge pull request #292 from deadc0de6/chmod

Browse Source 
Chmod
This commit is contained in:
deadc0de
2020-11-21 13:52:03 +01:00
committed by GitHub
parent 0ebbdf7a84 e0ff3efe04
commit 675c820606
51 changed files with 2967 additions and 919 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
docs/config-format.md
View File

@@ -46,6 +46,7 @@ Entry | Description
`src` | dotfile path within the `dotpath` (dotfile with empty `src` are ignored and considered installed, can use `variables` and `dynvariables`, make sure to quote)
`link` | define how this dotfile is installed. Possible values: *nolink*, *link*, *link_children* (see [Symlinking dotfiles](config.md#symlink-dotfiles)) (defaults to value of `link_dotfile_default`)
`actions` | list of action keys that need to be defined in the **actions** entry below (see [actions](config-details.md#entry-actions))
`chmod` | defines the file permission in octal notation to apply during installation (see [permissions](config.md#permissions))
`cmpignore` | list of patterns to ignore when comparing (enclose in quotes when using wildcards, see [ignore patterns](config.md#ignore-patterns))
`ignoreempty` | if true empty template will not be deployed (defaults to value of `ignoreempty`)
`instignore` | list of patterns to ignore when installing (enclose in quotes when using wildcards, see [ignore patterns](config.md#ignore-patterns))

25
docs/config.md
View File

@@ -59,6 +59,31 @@ Here are some rules on the use of variables in configs:
* external/imported `(dyn)variables` take precedence over
`(dyn)variables` defined inside the main config file
## Permissions
Dotdrop allows to control the permission applied to a dotfile using the
config dotfile entry [chmod](config-format.md#dotfiles-entry).
A [chmod](config-format.md#dotfiles-entry) entry on a directory is applied to the
directory only, not recursively.
On `import` the following rules are applied:
* if the `-m --preserve-mode` switch is provided the imported file permissions are
stored in a `chmod` entry
* if imported file permissions differ from umask then its permissions are automatically
stored in the `chmod` entry
* otherwise no `chmod` entry is added
On `install` the following rules are applied:
* 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`:
* if the permissions of the file in the filesystem differ from the dotfile in the `dotpath`
then the dotfile entry `chmod` is added/updated accordingly
## Symlink dotfiles
Dotdrop is able to install dotfiles in three different ways

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](global-config-files.md)
[Manage system dotfiles](system-config-files.md)
## 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
...
```

30
docs/usage.md
View File

@@ -226,6 +226,28 @@ dotdrop. It will:
For more options, see the usage with `dotdrop --help`
## Concurrency
The command line switch `-w --workers` if set to a value greater than one allows to use
multiple concurrent workers to execute an operation. It can be applied to the following
commands:
* `install`
* `compare`
* `update`
It should be set to a maximum of the number of cores available (usually returned
on linux by the command `nproc`).
It may speed up the operation but cannot be used interractively (it needs `-f --force` to be set
except for `compare`) and cannot be used with `-d --dry`. Also information printed to stdout/stderr
will probably be messed up.
**WARNING** this feature hasn't been extensively tested and is to be used at your own risk.
If you try it out and find any issue, please [report it](https://github.com/deadc0de6/dotdrop/issues).
Also if you find it useful and have been able to successfully speed up your operation when using
`-w --workers`, do please also report it [in an issue](https://github.com/deadc0de6/dotdrop/issues).
## Environment variables
Following environment variables can be used to specify different CLI options.
@@ -255,3 +277,11 @@ export DOTDROP_FORCE_NODEBUG=
```bash
export DOTDROP_TMPDIR="/tmp/dotdrop-tmp"
```
* `DOTDROP_WORKDIR`: overwrite the `workdir` defined in the config
```bash
export DOTDROP_WORKDIR="/tmp/dotdrop-workdir"
```
* `DOTDROP_WORKERS`: overwrite the `-w --workers` cli argument
```bash
export DOTDROP_WORKERS="10"
```