gunzip should not try to seek the stream, but an issue was reported
in #407, where it fails with
gzip: stdin: unexpected end of file
So we're writing to a file first just to be safer.
Fixes#407.
Pattern must match from the beginning (`##`).
Also don't quote ${ZIM_HOME}. We don't want to have an array like
('${ZIM_HOME}' '/path/to/zim_home'), so it needs to be unquoted for the
uniqueness to work.
to be simpler, and to teach users how to do it from outside Zsh.
Users might use provioning scripts to manage their dotfiles, and knowing
how to install from outside Zsh might be helpful in some cases.
See #400.
Closes#402
instead of allowing xargs to execute the action with no positional
parameters.
Also don't try to write to .latest_version if there's no write
permission. This is supposed to be a background/optional operation, so
we don't want to show an error message in this case.
And use Zsh globs instead of find with -exec, and find won't fail if
there's an error with the -exec command.
before initial check for latest version. Not all versions of Zsh or all
OSs are affected. Error seen with Zsh 5.6.2 running on FreeBSD is:
_zimfw_version_check:10: no such file or directory: /path/to/.latest_version
Last-minute minor fixes:
* Delete .latest_version after upgrading. Having a cache brings in these
complexities.
* Print warning to stderr, to distinguish it from the normal output.
* Update help to be in sync with the README.md.
as it was being used to update the login_init.zsh script. BUT the
function mentioned, which updates that script, would only be updated
after zimfw.zsh is sourced again, so no point in trying to call it at
this point.
so the normal output is focused on the given action, and output for
additional steps perfomed after the given action is only shown in
verbose mode.
Also, the output of wget is only shown in verbose mode. This is because
wget always shows some output (to stderr) even when there are no errors.
See https://serverfault.com/q/70889/302338
This should give a friendlier output.
See #360
Zim does not use/modify .zprofile in it's templates. For completeness/
performance, the .zprofile should be compiled/cleaned if present.
Ref: http://zsh.sourceforge.net/Intro/intro_3.htmlCloses#358
It fails with
_zimfw_build_init:8: unrecognized modifier `P'
The `:P` modifier was introduced in Zsh 5.3. Replace it by `:A`, as we
still want to keep compatibility with Zsh 5.2.
Fixes#349
Changes:
* Reduce the Zim "core" to a single file
* Simplify installation with an installation script (Closes#182)
* Put the configuration into .zshrc instead of a separate .zimrc
(Closes#288)
* Do not support themes that require promptinit (See #325)
* Generate a static script that does autoload the functions and source
the modules
This version is not backwards-compatible with previous versions, so a
new installation of Zim is required.
At least until Zsh version 5.7.1, no performance improvement is observed
out of using those.
In some cases, the performance is even worsened, like when using
autoload -w functions_digest.zwc
instead of
autoload func_name1 func_name2 ...
So we can have the following code in the zlogin template:
source ${ZIM_HOME}/login_init.zsh -q &!
instead of depending on the zimfw function there. This allows fixing the
issue were a non-interactive login shell currently yields:
command not found: zimfw.
To fully fix the issue, we also need a new zshenv template containing:
ZIM_HOME=${ZDOTDIR:-${HOME}}/.zim
Templates will be updated in the install script.
we want to be a universal Zsh framework, and send the message that
"less is less"! ;- )
Don't indent done and failed messages with an indicator, at the end of
actions, to differentiate them from intermediate okay and error messages.
and make code closer to the one in the manual pages (unless for our code
style). Why reinvent the wheel?
This last change makes the arguments to zrecompile shorter (passing
relative paths instead of full paths to each function file).
The number of arguments can be huge. There are 1143 of them currently
for /usr/local/Cellar/zsh/5.7.1/share/zsh/functions!
and have `zimfw clean` only do `clean-compiled` and `clean-dumpfile`.
Semantically, it makes much more sense because we will be then cleaning
temporary files that are later compiled/generated again, which is not
the case for a module (which we'll be uninstalling now instead of
cleaning).
