Zsh and Prezto files don't always reside in `~/`. Instead, they have
a more spec compliant location (`${ZDOTDIR:-$HOME}/`). Make them
unambiguous in the documentation. Likewise, for `$GNUPGHOME`.
Further, add instruction for optionally setting up Prezto in
`$XDG_CONFIG_HOME`.
While at this, also add clarification on relative ordering of some of
the modules, apply more formatting tweaks and doc improvements.
Detect `ls` provided by GNU Core Utilities upfront before applying
the relevant settings and aliases.
The revised logic takes the following aspects into consideration:
- `is-callable 'dircolors'` is not a sufficient test for verifying if
the `ls` in scope is _also_ provided by GNU Core Utilities. `ls` can
continue to be the one provided by BSD Core Utilities because of its
precedence in `$path`.
- The `ls` in scope anyway can be either GNU Utils provided or BSD Utils
provided depending on either `$path` precedence, soft link (via
`ln -s`), or wrapper function (via 'gnu-utility' module).
- So instead of '_guessing_' the possible one, just detect if it is from
GNU Utils and apply the relevant settings and aliases.
- Note that GNU prefixed `ls` (`gls`) is intentionally not honored in
this case to avoid possible conflict/shadowing with other `gls`
callable (can happen if 'git' module is used, for example).
Besides, honoring `gls` would imply we honor other commands (like
`mv`, `rm` etc.) to be consistent. We have a module 'gnu-utils'
dedicated for that after all.
General purpose reformating and rewording in (a few places). This should
also make markdown linting happier.
Prefer back-ticks wherever useful and use `console` for code blocks to
be executed on terminal.
Also, update references links wherever possible (including update from
'http://' to 'https://').
Remove `--protect-decmpfs` by default since hfs-compression specific
changes have been marked by upstream as broken since 3.1.3 and there is
little likelihood of that changing.
As curl bundled with macOS does not include `_curl` definitions, one
way to make `_curl` available is to install curl from Homebrew.
However, since curl from Hombrew is _keg-only_, its function path needs
to be explicitly included.
Change default `HISTFILE` path from `~/.zhistory` to more conventional
`~/.zsh_history`. This aligns better with Debian variants, macOS and
Oh My Zsh.
This would provide an easier onboarding experience to users coming to
Prezto from standard (framework free) zsh or from Oh My Zsh.
For existing Prezto users, we attempt to automatically rename old
`HISTFILE` to new one iff the old one exists and the new one doesn't.
However, if both old and new `HISTFILE` exist and the old one is more
recent, we just alert the user about what changed with a suggested way
to accommodate the change.
I think this should have been removed as part of 0a07ba27a2.
Currently I'm seeing this warning after updating to `master`:
```
Couldn't read file /Users/jeffwidman/.zprezto/modules/prompt/functions/prompt_powerlevel9k_setup containing theme powerlevel9k.
```
`compinit -i` doesn't always change zcompdump, which means that the
`compinit -C` condition fails to run until the completions change.
When we `compinit -i`, we should touch the file too to solve this.
Now that 'command-not-found' helper loading has been significantly
simplified and the startup time improved in the official Homebrew tap,
the workaround for script detection (and caching) can be removed.
> The {query} has to be percent-escaped in macOS 11.
Just replace `:` to `%3A` work fine.
But add function like this one I find on stackoverflow to encode the entire query string would be more robust.
```bash
urldecode() {
# urldecode <string>
local url_encoded="${1//+/ }"
printf '%b' "${url_encoded//%/\\x}"
}
```
When $WORKON_HOME is not set and $ENV_NAME is equal to
$PROJECT_ROOT/.venv which contains bin/activate then
the code wrongly assumes workon is available.
It should execute the second branch to source bin/activate.
Pyenv will install shims for commands that exist in any interpreter, even if it is not the current one. This means that a command may technically exist, but when executed will tell the user to try a different interpreter. The original check for pip in the Python module can fail for this reason, in particular on Ubuntu 20.04.
This change checks with pyenv whether pip really exists in the current interpreter to work around this problem and fixes a bug in pip command detection.
Indrajit Raychaudhuri