The motivation for this change comes from several reasons and
frustrations with the previous setup used here.
Firstly, the terminfo variables previously provided did not match those
of the familiar-to-me termcap environment variables, not even remotely
close. The color scheme the termcap variables creates is a largely
yellow-and-white theme, while the terminfo variables created a largely
blue-and-white theme. In addition to being unfamiliar, blue tends to be
somewhat hard to read on my dark theme terminals, so it had to go.
Secondly, in my efforts to update the terminfo variables to match the
colors provided by termcap, I found that bright colors (such as the
bright white used for underlined text) did not display correctly, and it
blatantly ignored any attempts to display colors in their default or
bright color variants. Due to the prevalence of underlined text in
manpages, this meant that I could not achieve the desired color scheme
whatsoever.
Finally, maintaining this convoluted `less` version check is something
I'd rather not do. Because terminfo is not universal and I typically use
stable distributions of linux tending away from the bleeding edge, I can
rely on termcap being available for `less` for some time to come, while
terminfo isn't yet available for Debian stable. Given that, I'd like to
maintain only a single set of color mappings for now. And unless I can
overcome the color issue mentioned in the previous paragraph, I doubt
I'll be interested in maintaining a parity between the two.
n.b. In the process of slimming these definitions down, I did a decent
amount of research to find parity in the text types identified by
terminfo and termcap. The following table details those findings. Note
that termcap variables would be set as environment variables in the
format `LESS_TERMCAP_var` and are set to an ANSI escape sequence for a
Select Graphic Rendition (see
https://stackoverflow.com/a/33206814/540162), and terminfo variables are
passed as arguments to `less` in the format `less -Dv` and are set to a
4-bit or 8-bit color string. (see `man less` on systems with `less
--version` >= 580)
| termcap | terminfo | |
|---------|----------|------------------------------------|
| mb | k | blinking text |
| md | d | bold text |
| me | | end bold/blinking text |
| so | s | reverse video (standout) text |
| se | | end reverse video text |
| us | u | underlined text |
| ue | | end underlined text |
| | B | binary characters |
| | C | control characters |
| | E | errors and info messages |
| | M | mark letters in status column |
| | N | line numbers enabled via -N option |
| | P | prompts |
| rs | R | rscroll character |
| | S | search results |
| | W | highlight enabled via -w option |
This bypasses an annoying issue when using both ~/.gitconfig and
~/.user.gitconfig, which is that there is no guarantee of the order
these configs are loaded. This means that configs loaded in
~/.user.gitconfig (which in this case is intended to override
~/.gitconfig) may not actually override those found in ~/.gitconfig. By
using `include.path`, they are loaded a second time, but it guarantees
they are loaded after all the configs in ~/.gitconfig, ensuring they are
used in cases where the key is present in both files.
This alias removes any output which would be generated. By default,
`nohup` generates a `nohup.out` file in the cwd or home directory with
the output from the executed program. Most of the time I don't need to
monitor the program's output, and when I do, I can easily run `\nohup
<program>` to circumvent this alias.
As far as external motd programs go, neofetch seems to be
better-maintained than screenfetch, and has some features I prefer like
incremental printing and a fairly robust configuration.
For a system which does not have a VSCode installation, other parts of
setup should still be attempted even if these particular configs can't
be put in place.
As-is, the `column -t` invocation works very poorly and is effectively
useless as it can't communicate the information it ought to. For the
time being (until the next Debian stable coreutils update) the format
`alias = 'cmd'` is more readable and useful. This commit also expands a
good bit on the ideal command chain of the post-coreutils update alias
and the possible issues left to solve after that implementation is done.
While `/bin/bash` is the default in many systems, it cannot be relied
upon for _all_ systems, particularly ones such as MacOS where the
default `/bin/bash` is a very old version. Instead, use the `bash`
executable from the system's PATH.
While these configs are useful in the event that I want to `git pull` on
feature branches and have them update from their source branch, I find
that in practice I rarely use this workflow. I generally only pull on
branches which track a remote branch directly, and I normally reach for
`git rebase` when updating feature branches from their source. These
configurations also interfere with my workflow of `git push` creating
the branch in my origin if absent.
Rather than re-constructing PS1 each time the prompt is called, it can
be built once. The portions of it which call functions are still called,
so there is no drawback to setting it and forgetting it.
When running as root (via `sudo su`, for instance), XDG_RUNTIME_DIR is
usually not set, which causes some warning messages to be printed prior
to screenfetch's output. I don't care about this, so I don't want to see
it.