when installing a module with the degit tool. Error was:
_zimfw_download_tarball:11: no such file or directory: /path/to/.zdegit
The .zdegit file is created as part of the module installation.
which auto detects the best tool available for installing a new module
or the tool used when an existing module was installed. This is now the
default tool and makes life automatically easier for users without git
installed.
that removes and then installs again the modules that failed any of the
"pre" checks. This runs the "pre" checks (as "prereinstall") and, if the
checks failed (return code is not 0), then proceeds with the reinstall
for each module.
Also minor change of the use of the word "upgrade", reserving it to mean
upgrading zimfw.
Fixes#542
as we also check the git URL in the pre action there.
Don't use _zimfw_source_zimrc with a flag when no _znames is needed
(flag 1) or _zfpaths, _zfunctions, _zcmds are needed (flag 2).
instead of if no ${ZIM_HOME} exists. If current user has no config file,
then most likely they're sourcing the init.zsh generated by another user
in the same machine.
Initially the idea was to not allow this so upgrades are disabled when
the script is installed using a package manager, but this is an
unnecessary complexity. Making it less smart and more predictable.
for write permission. Also, if ZIM_HOME is not defined, don't "autoload"
the zimfw function, since this is going to be a scenario where the user
only has something like `source /path/to/zim/init.zsh` in their .zshrc.
to zimfw.zsh or if it's a symlink or not a regular file. It does not
make sense to show a message to user saying "Run zimfw upgrade to
upgrade" if the action will then fail.
or if it's a symlink or not a regular file. This makes more sense now
that zimfw.zsh can exist outside ZIM_HOME, that the same file can be
used my multiple users in the same machine, and that it is going to be
possible to install it with a package manager once it's stable to do so.
Don't want to maintain extra code to allow zmodule to run outside zimfw.
This has no added benefit and might confuse users. If you were calling
zmodule in the shell just to get the help message, hopefully you can
look that up in the documentation instead.
This will allow creating modules that contain only externally generated
files. For example, this is how I currently use it to generate modules
for code that is supposed to be eval'ed:
zmodule-eval() {
local -r zcommand=${${=1}[1]} ztarget=${1//[^[:alnum:]]/-}.zsh
zmodule custom-${zcommand} --use mkdir --if-command ${zcommand} \
--cmd "if [[ ! {}/${ztarget} -nt \${commands[${zcommand}]} ]]; then ${1} >! {}/${ztarget}; zcompile -UR {}/${ztarget}; fi" \
--source ${ztarget}
}
zmodule-eval 'starship init zsh'
unfunction zmodule-eval
and replace the foreground color and bold expansions by ANSI escape
codes. This should make the print calls now safe and no expansion at all
should happen as we're using `-R` -- unless the `-e` flag is given.
Fixes#521. Closes#522
as it was before a34b8dab64.
Don't make zimfw hang in the foreground waiting for git to connect to
GitHub, mainly because the waiting can take too long in case of
connection issues or no network. Also set git timeout to 30 seconds so
background check also does hang for too long, just it case.
Fixes#514
