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
This was needed when we were using xargs, but we're already using zargs
instead for quite some time. Pro is that now common functions are reused
instead of repeated. Con (or change) is that due to that reuse, and in
favor of simplification, the warning for a module with git submodules in
degit is in a separate line from a separate print call now.
Also fix regressions from recent commits:
- Need to call _zimfw_source_zimrc twice with 1 and 2 flags instead of
with flag 3, since flag 2 must be used after module is installed or
updated.
- Need to call _zimfw_print_okay from the function that handles on-pull,
since we want to include the on-pull output in verbose mode. This
function was called just `handle` before, now it's called
_zimfw_pull_print_okay.
Still need to figure out how to return a final error code from
_zimfw_run_tool_action.
actions. Return 4 if there's a zimfw update from check-version. Don't
return a specific error code if there are module updates from check, as
it uses zargs to check all and each check runs in a separate shell. Need
to figure out how to propagate all that to a final error code.
See #503
Previous change fixed the old dumpfile vs. new dumpfile check, but
removed an existing (but flawled) old Zim fpath vs. new Zim fpath check.
We should be doing both checks the right way now.
