diff --git a/doc/builders/fetchers.chapter.md b/doc/builders/fetchers.chapter.md index ecff01894840..b86fffa46042 100644 --- a/doc/builders/fetchers.chapter.md +++ b/doc/builders/fetchers.chapter.md @@ -3,7 +3,7 @@ Building software with Nix often requires downloading source code and other files from the internet. `nixpkgs` provides *fetchers* for different protocols and services. Fetchers are functions that simplify downloading files. -## Caveats +## Caveats {#chap-pkgs-fetchers-caveats} Fetchers create [fixed output derivations](https://nixos.org/manual/nix/stable/#fixed-output-drvs) from downloaded files. Nix can reuse the downloaded files via the hash of the resulting derivation. diff --git a/doc/builders/images/binarycache.section.md b/doc/builders/images/binarycache.section.md index fe2772f33b4b..62e47dad7c66 100644 --- a/doc/builders/images/binarycache.section.md +++ b/doc/builders/images/binarycache.section.md @@ -6,7 +6,7 @@ Nix packages are most commonly shared between machines using [HTTP, SSH, or S3]( Note that this function is meant for advanced use-cases. The more idiomatic way to work with flat-file binary caches is via the [nix-copy-closure](https://nixos.org/manual/nix/stable/command-ref/nix-copy-closure.html) command. You may also want to consider [dockerTools](#sec-pkgs-dockerTools) for your containerization needs. -## Example +## Example {#sec-pkgs-binary-cache-example} The following derivation will construct a flat-file binary cache containing the closure of `hello`. diff --git a/doc/builders/images/dockertools.section.md b/doc/builders/images/dockertools.section.md index 2467739a1a5e..3ac4f224b5de 100644 --- a/doc/builders/images/dockertools.section.md +++ b/doc/builders/images/dockertools.section.md @@ -410,7 +410,7 @@ If the derivation is fully buildable (i.e. `nix-build` can be used on it), runni The behavior doesn't match `nix-shell` or `nix-build` exactly and this function is known not to work correctly for e.g. fixed-output derivations, content-addressed derivations, impure derivations and other special types of derivations. ::: -### Arguments +### Arguments {#ssec-pkgs-dockerTools-buildNixShellImage-arguments} `drv` @@ -473,7 +473,7 @@ The behavior doesn't match `nix-shell` or `nix-build` exactly and this function *Default:* (none) -### Example +### Example {#ssec-pkgs-dockerTools-buildNixShellImage-example} The following shows how to build the `pkgs.hello` package inside a Docker container built with `buildNixShellImage`. diff --git a/doc/builders/images/makediskimage.section.md b/doc/builders/images/makediskimage.section.md index c4566e753108..e50479c4e83e 100644 --- a/doc/builders/images/makediskimage.section.md +++ b/doc/builders/images/makediskimage.section.md @@ -12,12 +12,12 @@ Whereas for many web servers, applications, it is possible to work with a Nix st NixOS tests also use this function when preparing the VM. The `cptofs` method is used when `virtualisation.useBootLoader` is false (the default). Otherwise the second method is used. -## Features +## Features {#sec-make-disk-image-features} For reference, read the function signature source code for documentation on arguments: . Features are separated in various sections depending on if you opt for a Nix-store only image or a full NixOS image. -### Common +### Common {#sec-make-disk-image-features-common} - arbitrary NixOS configuration - automatic or bound disk size: `diskSize` parameter, `additionalSpace` can be set when `diskSize` is `auto` to add a constant of disk space @@ -29,7 +29,7 @@ Features are separated in various sections depending on if you opt for a Nix-sto - the current nixpkgs can be realized as a channel in the disk image, which will change the hash of the image when the sources are updated - additional store paths can be provided through `additionalPaths` -### Full NixOS image +### Full NixOS image {#sec-make-disk-image-features-full-image} - arbitrary contents with permissions can be placed in the target filesystem using `contents` - a `/etc/nixpkgs/nixos/configuration.nix` can be provided through `configFile` @@ -37,7 +37,7 @@ Features are separated in various sections depending on if you opt for a Nix-sto - EFI variables can be mutated during image production and the result is exposed in `$out` - boot partition size when partition table is `efi` or `hybrid` -### On bit-to-bit reproducibility +### On bit-to-bit reproducibility {#sec-make-disk-image-features-reproducibility} Images are **NOT** deterministic, please do not hesitate to try to fix this, source of determinisms are (not exhaustive) : @@ -47,7 +47,7 @@ Images are **NOT** deterministic, please do not hesitate to try to fix this, sou A `deterministic` flag is available for best efforts determinism. -## Usage +## Usage {#sec-make-disk-image-usage} To produce a Nix-store only image: ```nix diff --git a/doc/builders/special/makesetuphook.section.md b/doc/builders/special/makesetuphook.section.md index 90d75c5491cf..fee508dc29c2 100644 --- a/doc/builders/special/makesetuphook.section.md +++ b/doc/builders/special/makesetuphook.section.md @@ -12,7 +12,7 @@ pkgs.makeSetupHook { } ./script.sh ``` -#### setup hook that depends on the hello package and runs hello and @shell@ is substituted with path to bash +#### setup hook that depends on the hello package and runs hello and @shell@ is substituted with path to bash {#sec-pkgs.makeSetupHook-usage-example} ```nix pkgs.makeSetupHook { @@ -27,7 +27,7 @@ pkgs.makeSetupHook { '') ``` -## Attributes +## Attributes {#sec-pkgs.makeSetupHook-attributes} * `name` Set the name of the hook. * `propagatedBuildInputs` Runtime dependencies (such as binaries) of the hook. diff --git a/doc/builders/special/mkshell.section.md b/doc/builders/special/mkshell.section.md index 73cc57f485bd..96d43535955f 100644 --- a/doc/builders/special/mkshell.section.md +++ b/doc/builders/special/mkshell.section.md @@ -20,7 +20,7 @@ pkgs.mkShell { } ``` -## Attributes +## Attributes {#sec-pkgs-mkShell-attributes} * `name` (default: `nix-shell`). Set the name of the derivation. * `packages` (default: `[]`). Add executable packages to the `nix-shell` environment. @@ -29,7 +29,7 @@ pkgs.mkShell { ... all the attributes of `stdenv.mkDerivation`. -## Building the shell +## Building the shell {#sec-pkgs-mkShell-building} This derivation output will contain a text file that contains a reference to all the build inputs. This is useful in CI where we want to make sure that diff --git a/doc/builders/testers.chapter.md b/doc/builders/testers.chapter.md index a0f0f97f9d53..a644262fd9c9 100644 --- a/doc/builders/testers.chapter.md +++ b/doc/builders/testers.chapter.md @@ -178,7 +178,7 @@ letting NixOS invoke Nixpkgs anew. If a test machine needs to set NixOS options under `nixpkgs`, it must set only the `nixpkgs.pkgs` option. -### Parameter +### Parameter {#tester-nixosTest-parameter} A [NixOS VM test network](https://nixos.org/nixos/manual/index.html#sec-nixos-tests), or path to it. Example: @@ -200,7 +200,7 @@ A [NixOS VM test network](https://nixos.org/nixos/manual/index.html#sec-nixos-te } ``` -### Result +### Result {#tester-nixosTest-result} A derivation that runs the VM test. diff --git a/doc/contributing/submitting-changes.chapter.md b/doc/contributing/submitting-changes.chapter.md index 96e2ecf970cb..30fe4fa47d0d 100644 --- a/doc/contributing/submitting-changes.chapter.md +++ b/doc/contributing/submitting-changes.chapter.md @@ -290,7 +290,7 @@ Other examples of reasons are: - The previous download links were all broken - Crash when starting on some X11 systems -#### Acceptable backport criteria +#### Acceptable backport criteria {#acceptable-backport-criteria} The stable branch does have some changes which cannot be backported. Most notable are breaking changes. The desire is to have stable users be uninterrupted when updating packages. diff --git a/doc/languages-frameworks/agda.section.md b/doc/languages-frameworks/agda.section.md index d9ed56fb83fc..ff3d70ef0c62 100644 --- a/doc/languages-frameworks/agda.section.md +++ b/doc/languages-frameworks/agda.section.md @@ -216,7 +216,7 @@ you can test whether it builds correctly by writing in a comment: @ofborg build agdaPackages.iowa-stdlib ``` -### Maintaining Agda packages +### Maintaining Agda packages {#agda-maintaining-packages} As mentioned before, the aim is to have a compatible, and up-to-date package set. These two conditions sometimes exclude each other: diff --git a/doc/languages-frameworks/beam.section.md b/doc/languages-frameworks/beam.section.md index 0ef0c830ef8c..4c1650781f05 100644 --- a/doc/languages-frameworks/beam.section.md +++ b/doc/languages-frameworks/beam.section.md @@ -281,11 +281,11 @@ mkShell { } ``` -### Using an overlay +### Using an overlay {#beam-using-overlays} If you need to use an overlay to change some attributes of a derivation, e.g. if you need a bugfix from a version that is not yet available in nixpkgs, you can override attributes such as `version` (and the corresponding `hash`) and then use this overlay in your development environment: -#### `shell.nix` +#### `shell.nix` {#beam-using-overlays-shell.nix} ```nix let diff --git a/doc/languages-frameworks/chicken.section.md b/doc/languages-frameworks/chicken.section.md index d8c35bd20c50..d329943dc3c2 100644 --- a/doc/languages-frameworks/chicken.section.md +++ b/doc/languages-frameworks/chicken.section.md @@ -4,7 +4,7 @@ [R⁵RS](https://schemers.org/Documents/Standards/R5RS/HTML/)-compliant Scheme compiler. It includes an interactive mode and a custom package format, "eggs". -## Using Eggs +## Using Eggs {#sec-chicken-using} Eggs described in nixpkgs are available inside the `chickenPackages.chickenEggs` attrset. Including an egg as a build input is @@ -22,7 +22,7 @@ might write: Both `chicken` and its eggs have a setup hook which configures the environment variables `CHICKEN_INCLUDE_PATH` and `CHICKEN_REPOSITORY_PATH`. -## Updating Eggs +## Updating Eggs {#sec-chicken-updating-eggs} nixpkgs only knows about a subset of all published eggs. It uses [egg2nix](https://github.com/the-kenny/egg2nix) to generate a @@ -36,7 +36,7 @@ $ cd pkgs/development/compilers/chicken/5/ $ egg2nix eggs.scm > eggs.nix ``` -## Adding Eggs +## Adding Eggs {#sec-chicken-adding-eggs} When we run `egg2nix`, we obtain one collection of eggs with mutually-compatible versions. This means that when we add new eggs, we may diff --git a/doc/languages-frameworks/cuelang.section.md b/doc/languages-frameworks/cuelang.section.md index ef408c7bb19b..86304208aa20 100644 --- a/doc/languages-frameworks/cuelang.section.md +++ b/doc/languages-frameworks/cuelang.section.md @@ -7,7 +7,7 @@ - do configuration akin to [Dhall Lang](https://dhall-lang.org/) - perform data validation -## Cuelang schema quick start +## Cuelang schema quick start {#cuelang-quickstart} Cuelang schemas are similar to JSON, here is a quick cheatsheet: @@ -21,7 +21,7 @@ Cuelang schemas are similar to JSON, here is a quick cheatsheet: - Read to learn more about the semantics. - Read to learn about the language specification. -## `writeCueValidator` +## `writeCueValidator` {#cuelang-writeCueValidator} Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validation script based on the provided Cuelang schema. diff --git a/doc/languages-frameworks/haskell.section.md b/doc/languages-frameworks/haskell.section.md index ec123e7c7bac..4b4f52312940 100644 --- a/doc/languages-frameworks/haskell.section.md +++ b/doc/languages-frameworks/haskell.section.md @@ -160,7 +160,7 @@ All `haskell.packages.*` package sets use the same package descriptions and the of versions by default. There are however GHC version specific override `.nix` files to loosen this a bit. -### Dependency resolution +### Dependency resolution {#haskell-dependency-resolution} Normally when you build Haskell packages with `cabal-install`, `cabal-install` does dependency resolution. It will look at all Haskell package versions known @@ -230,7 +230,7 @@ specification, test suites, benchmarks etc. by compiling and invoking the package's `Setup.hs`. It does *not* use or invoke the `cabal-install` binary, but uses the underlying `Cabal` library instead. -### General arguments +### General arguments {#haskell-derivation-args} `pname` : Package name, assumed to be the same as on Hackage (if applicable) @@ -479,7 +479,7 @@ are especially useful when writing [overrides](#haskell-overriding-haskell-packa when you want to make sure that they are definitely included. However, it is recommended to use the more accurate ones listed above when possible. -### Meta attributes +### Meta attributes {#haskell-derivation-meta} `haskellPackages.mkDerivation` accepts the following attributes as direct arguments which are transparently set in `meta` of the resulting derivation. See @@ -714,7 +714,7 @@ editor plugin to achieve this. ## Overriding Haskell packages {#haskell-overriding-haskell-packages} -### Overriding a single package +### Overriding a single package {#haskell-overriding-a-single-package} @@ -803,7 +803,7 @@ lib.pipe my-haskell-package [ ] ``` -#### `haskell.lib.compose` +#### `haskell.lib.compose` {#haskell-haskell.lib.compose} The base interface for all overriding is the following function: @@ -826,7 +826,7 @@ following overview. Refer to the [documentation of `haskellPackages.mkDerivation`](#haskell-mkderivation) for a more detailed description of the effects of the respective arguments. -##### Packaging Helpers +##### Packaging Helpers {#haskell-packaging-helpers} `overrideSrc { src, version } drv` : Replace the source used for building `drv` with the path or derivation given @@ -875,7 +875,7 @@ sometimes necessary when working with versioned packages in altogether. Useful if it fails to evaluate cleanly and is causing noise in the evaluation errors tab on Hydra. -##### Development Helpers +##### Development Helpers {#haskell-development-helpers} `sdistTarball drv` : Create a source distribution tarball like those found on Hackage @@ -913,7 +913,7 @@ for debugging with e.g. `gdb`. -##### Trivial Helpers +##### Trivial Helpers {#haskell-trivial-helpers} `doJailbreak drv` : Sets the `jailbreak` argument to `true` for `drv`. @@ -998,7 +998,7 @@ benchmark component. `dontCoverage drv` : Sets the `doCoverage` argument to `false` for `drv`. -#### Library functions in the Haskell package sets +#### Library functions in the Haskell package sets {#haskell-package-set-lib-functions} Some library functions depend on packages from the Haskell package sets. Thus they are exposed from those instead of from `haskell.lib.compose` which can only access what is @@ -1062,7 +1062,7 @@ it does for the unstable branches. ## F.A.Q. {#haskell-faq} -### Why is topic X not covered in this section? Why is section Y missing? +### Why is topic X not covered in this section? Why is section Y missing? {#haskell-why-not-covered} We have been working on [moving the nixpkgs Haskell documentation back into the nixpkgs manual](https://github.com/NixOS/nixpkgs/issues/121403). Since this diff --git a/doc/languages-frameworks/javascript.section.md b/doc/languages-frameworks/javascript.section.md index 76cf6e03c257..6d5e465ec337 100644 --- a/doc/languages-frameworks/javascript.section.md +++ b/doc/languages-frameworks/javascript.section.md @@ -6,16 +6,16 @@ This contains instructions on how to package javascript applications. The various tools available will be listed in the [tools-overview](#javascript-tools-overview). Some general principles for packaging will follow. Finally some tool specific instructions will be given. -## Getting unstuck / finding code examples +## Getting unstuck / finding code examples {#javascript-finding-examples} If you find you are lacking inspiration for packing javascript applications, the links below might prove useful. Searching online for prior art can be helpful if you are running into solved problems. -### Github +### Github {#javascript-finding-examples-github} - Searching Nix files for `mkYarnPackage`: - Searching just `flake.nix` files for `mkYarnPackage`: -### Gitlab +### Gitlab {#javascript-finding-examples-gitlab} - Searching Nix files for `mkYarnPackage`: - Searching just `flake.nix` files for `mkYarnPackage`: @@ -105,7 +105,7 @@ After you have identified the correct system, you need to override your package }); ``` -### Adding and Updating Javascript packages in nixpkgs +### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages} To add a package from NPM to nixpkgs: @@ -140,7 +140,7 @@ To update NPM packages in nixpkgs, run the same `generate.sh` script: ./pkgs/development/node-packages/generate.sh ``` -#### Git protocol error +#### Git protocol error {#javascript-git-error} Some packages may have Git dependencies from GitHub specified with `git://`. GitHub has [disabled unecrypted Git connections](https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git), so you may see the following error when running the generate script: @@ -288,7 +288,7 @@ configurePhase = '' This will generate a derivation including the `node_modules` directory. If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way. -#### Overriding dependency behavior +#### Overriding dependency behavior {#javascript-mkYarnPackage-overriding-dependencies} In the `mkYarnPackage` record the property `pkgConfig` can be used to override packages when you encounter problems building. diff --git a/doc/languages-frameworks/pkg-config.section.md b/doc/languages-frameworks/pkg-config.section.md index fb6fee997d6f..75cbdaeb6fe8 100644 --- a/doc/languages-frameworks/pkg-config.section.md +++ b/doc/languages-frameworks/pkg-config.section.md @@ -4,7 +4,7 @@ Nixpkgs provides a couple of facilities for working with this tool. -## Writing packages providing pkg-config modules +## Writing packages providing pkg-config modules {#pkg-config-writing-packages} Packages should set `meta.pkgConfigModules` with the list of package config modules they provide. They should also use `testers.testMetaPkgConfig` to check that the final built package matches that list. @@ -29,9 +29,9 @@ stdenv.mkDerivation (finalAttrs: { }) ``` -## Accessing packages via pkg-config module name +## Accessing packages via pkg-config module name {#sec-pkg-config-usage} -### Within Nixpkgs +### Within Nixpkgs {#sec-pkg-config-usage-internal} A [setup hook](#setup-hook-pkg-config) is bundled in the `pkg-config` package to bring a derivation's declared build inputs into the environment. This will populate environment variables like `PKG_CONFIG_PATH`, `PKG_CONFIG_PATH_FOR_BUILD`, and `PKG_CONFIG_PATH_HOST` based on: @@ -44,7 +44,7 @@ For more details see the section on [specifying dependencies in general](#ssec-s Normal pkg-config commands to look up dependencies by name will then work with those environment variables defined by the hook. -### Externally +### Externally {#sec-pkg-config-usage-external} The `defaultPkgConfigPackages` package set is a set of aliases, named after the modules they provide. This is meant to be used by language-to-nix integrations. diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md index a65cea533bc0..88d57618d05d 100644 --- a/doc/languages-frameworks/python.section.md +++ b/doc/languages-frameworks/python.section.md @@ -1117,7 +1117,7 @@ with import {}; in python.withPackages(ps: [ps.blaze])).env ``` -#### Optional extra dependencies +#### Optional extra dependencies {#python-optional-dependencies} Some packages define optional dependencies for additional features. With `setuptools` this is called `extras_require` and `flit` calls it @@ -1801,14 +1801,14 @@ The following rules are desired to be respected: * Attribute names in `python-packages.nix` should be sorted alphanumerically to avoid merge conflicts and ease locating attributes. -## Package set maintenance +## Package set maintenance {#python-package-set-maintenance} The whole Python package set has a lot of packages that do not see regular updates, because they either are a very fragile component in the Python ecosystem, like for example the `hypothesis` package, or packages that have no maintainer, so maintenance falls back to the package set maintainers. -### Updating packages in bulk +### Updating packages in bulk {#python-package-bulk-updates} There is a tool to update alot of python libraries in bulk, it exists at `maintainers/scripts/update-python-libraries` with this repository. @@ -1836,7 +1836,7 @@ would be: $ maintainers/scripts/update-python-libraries --target minor --commit --use-pkgs-prefix pkgs/development/python-modules/**/default.nix ``` -## CPython Update Schedule +## CPython Update Schedule {#python-cpython-update-schedule} With [PEP 602](https://www.python.org/dev/peps/pep-0602/), CPython now follows a yearly release cadence. In nixpkgs, all supported interpreters diff --git a/doc/languages-frameworks/ruby.section.md b/doc/languages-frameworks/ruby.section.md index d1265097d206..f1953500fa32 100644 --- a/doc/languages-frameworks/ruby.section.md +++ b/doc/languages-frameworks/ruby.section.md @@ -201,7 +201,7 @@ $ nix-shell --run 'ruby -rpg -e "puts PG.library_version"' Of course for this use-case one could also use overlays since the configuration for `pg` depends on the `postgresql` alias, but for demonstration purposes this has to suffice. -### Platform-specific gems +### Platform-specific gems {#ruby-platform-specif-gems} Right now, bundix has some issues with pre-built, platform-specific gems: [bundix PR #68](https://github.com/nix-community/bundix/pull/68). Until this is solved, you can tell bundler to not use platform-specific gems and instead build them from source each time: diff --git a/doc/languages-frameworks/vim.section.md b/doc/languages-frameworks/vim.section.md index 3490b2576121..39e38c6a123d 100644 --- a/doc/languages-frameworks/vim.section.md +++ b/doc/languages-frameworks/vim.section.md @@ -166,8 +166,8 @@ in If your package requires building specific parts, use instead `pkgs.vimUtils.buildVimPlugin`. -### Specificities for some plugins -#### Treesitter +### Specificities for some plugins {#vim-plugin-specificities} +#### Treesitter {#vim-plugin-treesitter} By default `nvim-treesitter` encourages you to download, compile and install the required Treesitter grammars at run time with `:TSInstall`. This works @@ -244,7 +244,7 @@ Alternatively, set the number of processes to a lower count to avoid rate-limiti ./pkgs/applications/editors/vim/plugins/update.py --proc 1 ``` -## How to maintain an out-of-tree overlay of vim plugins ? +## How to maintain an out-of-tree overlay of vim plugins ? {#vim-out-of-tree-overlays} You can use the updater script to generate basic packages out of a custom vim plugin list: diff --git a/doc/manual.xml b/doc/manual.xml index ccbaf40586d1..8aca36017684 100644 --- a/doc/manual.xml +++ b/doc/manual.xml @@ -1,19 +1,20 @@ + xmlns:xi="http://www.w3.org/2001/XInclude" + xml:id="nixpkgs-manual"> Nixpkgs Manual Version - + Using Nixpkgs - + Standard environment @@ -21,7 +22,7 @@ - + Builders @@ -32,7 +33,7 @@ - + Contributing to Nixpkgs diff --git a/doc/stdenv/meta.chapter.md b/doc/stdenv/meta.chapter.md index 1fca829aa597..0b4777efdb8c 100644 --- a/doc/stdenv/meta.chapter.md +++ b/doc/stdenv/meta.chapter.md @@ -101,7 +101,7 @@ $ cd path/to/nixpkgs $ nix-build -A your-package.tests ``` -#### Package tests +#### Package tests {#var-meta-tests-packages} Tests that are part of the source package are often executed in the `installCheckPhase`. @@ -113,7 +113,7 @@ Prefer `passthru.tests` for tests that are introduced in nixpkgs because: For more on how to write and run package tests, see . -#### NixOS tests +#### NixOS tests {#var-meta-tests-nixos} The NixOS tests are available as `nixosTests` in parameters of derivations. For instance, the OpenSMTPD derivation includes lines similar to: diff --git a/doc/stdenv/stdenv.chapter.md b/doc/stdenv/stdenv.chapter.md index 6f3f2b446042..081d1e778fe8 100644 --- a/doc/stdenv/stdenv.chapter.md +++ b/doc/stdenv/stdenv.chapter.md @@ -703,7 +703,7 @@ The prefix under which the package must be installed, passed via the `--prefix` The key to use when specifying the prefix. By default, this is set to `--prefix=` as that is used by the majority of packages. -##### `dontAddStaticConfigureFlags` +##### `dontAddStaticConfigureFlags` {#var-stdenv-dontAddStaticConfigureFlags} By default, when building statically, stdenv will try to add build system appropriate configure flags to try to enable static builds. @@ -1095,15 +1095,15 @@ postInstall = '' Performs string substitution on the contents of \, writing the result to \. The substitutions in \ are of the following form: -#### `--replace` \ \ +#### `--replace` \ \ {#fun-substitute-replace} Replace every occurrence of the string \ by \. -#### `--subst-var` \ +#### `--subst-var` \ {#fun-substitute-subst-var} Replace every occurrence of `@varName@` by the contents of the environment variable \. This is useful for generating files from templates, using `@...@` in the template as placeholders. -#### `--subst-var-by` \ \ +#### `--subst-var-by` \ \ {#fun-substitute-subst-var-by} Replace every occurrence of `@varName@` by the string \. @@ -1244,7 +1244,7 @@ Multiple paths can be specified. patchShebangs [--build | --host] PATH... ``` -##### Flags +##### Flags {#patch-shebangs.sh-invocation-flags} `--build` : Look up commands available at build time @@ -1252,7 +1252,7 @@ patchShebangs [--build | --host] PATH... `--host` : Look up commands available at run time -##### Examples +##### Examples {#patch-shebangs.sh-invocation-examples} ```sh patchShebangs --host /nix/store/-hello-1.0/bin @@ -1339,7 +1339,7 @@ Similarly, the CC Wrapper follows the Bintools Wrapper in defining standard envi Here are some more packages that provide a setup hook. Since the list of hooks is extensible, this is not an exhaustive list. The mechanism is only to be used as a last resort, so it might cover most uses. -### Other hooks +### Other hooks {#stdenv-other-hooks} Many other packages provide hooks, that are not part of `stdenv`. You can find these in the [Hooks Reference](#chap-hooks).