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

Fix links

Browse Source
This commit is contained in:
John T. Wodder II
2021-10-05 12:30:59 -04:00
parent 60550424ca
commit 7c32b1a2fc
9 changed files with 22 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/config-details.md
View File

@@ -365,7 +365,7 @@ profiles:
Here profile *host1* contains all the dotfiles defined for *host2* plus `f_xinitrc`.
For more advanced use-cases, variables
([variables](config.md#variables) and [dynvariables](#entry-dynvariables))
([variables](config.md#variables) and [dynvariables](#dynvariables-entry))
can be used to specify the profile to include in a profile:
For example:

6
docs/config-format.md
View File

@@ -29,8 +29,8 @@ Entry | Description | Default
`import_variables` | List of paths to load variables from (absolute paths or relative to the config file location; see [Import variables from file](config-details.md#import_variables-entry)) | -
`instignore` | List of patterns to ignore when installing, applied to all dotfiles (enclose in quotes when using wildcards; see [ignore patterns](config.md#ignore-patterns)) | -
`keepdot` | Preserve leading dot when importing hidden file in the `dotpath` | false
`link_dotfile_default` | Set a dotfile's `link` attribute to this value when undefined. Possible values: *nolink*, *link* (See [Symlinking dotfiles](config.md#symlink-dotfiles)) | `nolink`
`link_on_import` | Set a dotfile's `link` attribute to this value when importing. Possible values: *nolink*, *link* [Symlinking dotfiles](config.md#symlink-dotfiles)) | `nolink`
`link_dotfile_default` | Set a dotfile's `link` attribute to this value when undefined. Possible values: *nolink*, *link* (See [Symlinking dotfiles](config.md#symlinking-dotfiles)) | `nolink`
`link_on_import` | Set a dotfile's `link` attribute to this value when importing. Possible values: *nolink*, *link* [Symlinking dotfiles](config.md#symlinking-dotfiles)) | `nolink`
`longkey` | Use long keys for dotfiles when importing (See [Import dotfiles](usage.md#import-dotfiles)) | false
`minversion` | (*for internal use, do not modify*) Provides the minimal dotdrop version to use | -
`showdiff` | On install, show a diff before asking to overwrite (See `--showdiff`) | false
@@ -47,7 +47,7 @@ Entry | Description
-------- | -------------
`dst` | Where this dotfile needs to be deployed (dotfiles with empty `dst` are ignored and considered installed, can use `variables`, make sure to quote)
`src` | Dotfile path within the `dotpath` (dotfiles with empty `src` are ignored and considered installed, can use `variables`, make sure to quote)
`link` | Defines 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`)
`link` | Defines how this dotfile is installed. Possible values: *nolink*, *link*, *link_children* (See [Symlinking dotfiles](config.md#symlinking-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#actions-entry))
`chmod` | Defines the file permissions 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))

18
docs/config.md
View File

@@ -37,10 +37,10 @@ but those are resolved when the action/transformation is executed
The following variables are available in the config files:
* [Variables defined in the config](config-details.md#entry-variables)
* [Interpreted variables defined in the config](config-details.md#entry-dynvariables)
* [User variables defined in the config](config-details.md#entry-uservariables)
* [Profile variables defined in the config](config-details.md#entry-profile-variables)
* [Variables defined in the config](config-details.md#variables-entry)
* [Interpreted variables defined in the config](config-details.md#dynvariables-entry)
* [User variables defined in the config](config-details.md#uservariables-entry)
* [Profile variables defined in the config](config-details.md#profile-variables-entry)
* Environment variables: `{{@@ env['MY_VAR'] @@}}`
* Dotdrop header: `{{@@ header() @@}}` (see [Dotdrop header](templating.md#dotdrop-header))
@@ -51,17 +51,17 @@ then be available during [templating](templating.md).
Here are some rules on the use of variables in configs:
* [Interpreted variables](config-details.md#entry-dynvariables) are executed in their own file.
* [Interpreted variables](config-details.md#entry-dynvariables) and
[variables](config-details.md#entry-variables) are templated before
[interpreted variables](config-details.md#entry-dynvariables) are executed.
* [Interpreted variables](config-details.md#dynvariables-entry) are executed in their own file.
* [Interpreted variables](config-details.md#dynvariables-entry) and
[variables](config-details.md#variables-entry) are templated before
[interpreted variables](config-details.md#dynvariables-entry) are executed.
* Config files do not have access to variables defined above in the import tree.
* `dynvariables` take precedence over `variables`.
* Profile `(dyn)variables` take precedence over any other `(dyn)variables`.
* Profile `(dyn)variables` take precedence over profile's included `(dyn)variables`.
* External/imported `(dyn)variables` take precedence over
`(dyn)variables` defined inside the main config file.
* [User variables](config-details.md#entry-uservariables) are ignored if
* [User variables](config-details.md#uservariables-entry) are ignored if
any other variable with the same key is defined.
## Permissions

2
docs/howto/append.md
View File

@@ -2,7 +2,7 @@
Sometimes it might be useful to be able to append some text to a
file. Dotdrop is able to do that with the help of
[actions](../config-details.md#entry-actions) and a temporary file.
[actions](../config-details.md#actions-entry) and a temporary file.
Below is a config example to append to a file:
```yaml

2
docs/howto/create-special-files.md
View File

@@ -1,7 +1,7 @@
# Create files on install
One way to create symlinks (or any other special file) is to use a combination of
[actions](../config-details.md#entry-actions) and a *fake* dotfile.
[actions](../config-details.md#actions-entry) and a *fake* dotfile.
Let's say, for example, you have a list of directories you want to link
from under `~/.original` to `~/symlinks`.

4
docs/howto/merge-files-when-installing.md
View File

@@ -48,12 +48,12 @@ Dotdrop will then automagically include the files into your vimrc when handling
## Merge all files in a directory
To include all files in a directory, a combination of
[dynvariables](../config-details.md#entry-dynvariables)
[dynvariables](../config-details.md#dynvariables-entry)
and [Jinja2 directives](https://jinja.palletsprojects.com/en/2.11.x/) have to be used.
Let's say all files in `<dotpath>/toinclude` need to be included into a dotfile.
First define a [dynvariables](../config-details.md#entry-dynvariables)
First define a [dynvariables](../config-details.md#dynvariables-entry)
in the config file which will look for files to include in the above directory:
```yaml
dynvariables:

4
docs/howto/prompt-user-for-variables.md
View File

@@ -1,12 +1,12 @@
# Prompt user for variables
With the use of [uservariables](../config-details.md#entry-uservariables),
With the use of [uservariables](../config-details.md#uservariables-entry),
one can define specific variables that need to be initially filled in manually
by the user on first run.
The provided values are then automatically saved by dotdrop to `uservariables.yaml`,
which can be included in the main config as a file from which variables are imported
using [import_variables](../config-details.md#entry-import_variables).
using [import_variables](../config-details.md#import_variables-entry).
Let's say, for example, that you want to manually provide the email value
on new hosts you deploy your dotfiles to.

4
docs/howto/sensitive-dotfiles.md
View File

@@ -47,7 +47,7 @@ $ cp <encrypted-version-of-secret> dotfiles/secret
* Commit and push the changes
See [transformations](../config-details.md#entry-transformations).
See [transformations](../config-details.md#transformations-entry).
## Load passphrase from file
@@ -67,4 +67,4 @@ trans_read:
_gpg: "gpg2 --batch --yes --passphrase-file <(cat {{@@ gpg_password_file @@}}) -q --for-your-eyes-only --no-tty -d {0} > {1}"
```
See [transformations](../config-details.md#entry-transformations).
See [transformations](../config-details.md#transformations-entry).

2
docs/howto/sharing-content.md
View File

@@ -66,7 +66,7 @@ export DB_PORT='4521'
The previous method, albeit flexible, is a bit cumbersome for some use cases.
For example, when the dotfiles belong to different profiles, the cleanest
solution consists of using
[profile variables](../config-details.md#entry-profile-variables). This is achieved by:
[profile variables](../config-details.md#profile-variables-entry). This is achieved by:
1. Creating the merged dotfile with an arbitrary name somewhere in `dotpath`.
2. Adding some variables in the merged dotfile via templating.