Automated consumers can use 'sed 1d' or similar to remove this header.
This probably makes this output *easier* to consume correctly. Having
this header show up in consumers' terminal or log output is probably not
useful, but hiding it without hiding all error messages would have been
more troublesome that just stripping it from stdout.
I.e., previously, unsophisticated use would show undesired output:
$ some-other-tool
This attribute set contains:
This attribute set contains:
This attribute set contains:
This attribute set contains:
<Actual some-other-tool output>
The simplest way to hide this undesired output would have been
nixos-option ... 2>/dev/null, which would hide all error messages.
We do not wish to encourage that.
Correct use would have been something like:
nixos-option ... 2> >( grep --line-buffered -v 'This attribute set contains:')
After this change, correct use is simpler:
nixos-option ... | sed 1d
or
nixos-option ... | sed '1/This attribute set contains:/d'
if the caller don't know if this invocation of nixos-option will yield
an attribute listing or an option description.
Switch from convention "appease clang-tidy --checks='*'" to
"References are like non-nullptr pointers". The clang-tidy check
"google-runtime-references" complains about non-const reference
arguments, but this is not a convention used in Nix.
Switch from convention "appease clang-tidy --checks='*'" to
"References are like non-nullptr pointers". The clang-tidy check
"google-runtime-references" complains about non-const reference
arguments, but this is not a convention used in Nix.
Switch from convention "appease clang-tidy --checks='*'" to
"References are like non-nullptr pointers". The clang-tidy check
"google-runtime-references" complains about non-const reference
arguments, but this is not a convention used in Nix.
I don't think this matters. As long as one or the other of these is
a std::string, I get an operator== that looks at content rather than
pointer equality. I picked casting the constant over casting the dynamic
thing in hopes that the compiler would have a better chance at optimizing
away any runtime cost.
Deferring to reviewer.
This is important because this contains some code copied from nix (as an
interim expediency until that functionality can be exported via nix's
API). The license specified here must be compatible with this borrowing.
Select the same license that nix is released under: lgpl2Plus.
Specifically, with
clang-format --style='{ IndentWidth: 4, BreakBeforeBraces: Mozilla, ColumnLimit: 120, PointerAlignment: Middle }'
which was the clang-format invocation that produced the fewest diffs on
the nix source out of ~20 that I tried.
Also add --all, which shows the value of all options. Diffing the --all
output on either side of contemplated changes is a lovely way to better
understand what's going on inside nixos.
In commit e8e191a1be9d after v2.0.0, nerdfonts switched from #!/bin/bash
to #!/usr/bin/env bash. Rather than synchronizing this patching with
that change, just use patchShebangs which handles both cases.
There is a bug in this feature: It allows extra arguments to leak in
from the environment. For example:
$ export extraFlagsArray=date
$ man ls
Note that you get the man page for date rather than for ls. This happens
because 'man' happens to use a wrapper (to add groff to its PATH).
An attempt to fix this was made in 5ae18574fc in PR #19328 for
issue #2537, but 1. That change didn't actually fix the problem because
it addressed makeWrapper's environment during the build process, not the
constructed wrapper script's environment after installation, and 2. That
change was apparently accidentally lost when merged with 7ff6eec5fd.
Rather than trying to fix the bug again, we remove the extraFlagsArray
feature, since it has never been used in the public repo in the ten
years it has been available.
wrapAclocal continues to use its own, separate flavor of extraFlagsArray
in a more limited context. The analogous bug there was fixed in
4d7d10da6b in 2011.
Chuck