Package Details: zsh-zim-git r606.bd765df-1

Git Clone URL: https://aur.archlinux.org/zsh-zim-git.git (read-only, click to copy)
Package Base: zsh-zim-git
Description: ZIM - Zsh IMproved
Upstream URL: https://github.com/zimfw/zimfw
Keywords: improved plugin theme vim zim zsh
Licenses: MIT
Submitter: ishitatsuyuki
Maintainer: carbolymer (Rhinoceros)
Last Packager: Rhinoceros
Votes: 19
Popularity: 0.000000
First Submitted: 2015-12-28 02:13 (UTC)
Last Updated: 2022-01-18 13:11 (UTC)

Pinned Comments

carbolymer commented on 2021-01-11 21:41 (UTC) (edited on 2021-01-22 07:46 (UTC) by carbolymer)

Ugh, it was a PITA to create this package. Please note that errors are silenced, so if you have any issues with zim, remove &>/dev/null from your /etc/zshrc - https://aur.archlinux.org/cgit/aur.git/tree/zshrc?h=zsh-zim-git&id=5a378e94d516c57d39629de545b78b0f020d86a4

I had to do it this way: $ZIM_HOME is only writable by root and zim constantly tries to update & recompile itself (=write to $ZIM_HOME), which results in permission errors when starting zsh as a normal user.

If you want to add/remove a module:

  1. Add a respective zmodule in /etc/zsh/zimrc
  2. Run as root: zimfw install && zsh

Latest Comments

Rhinoceros commented on 2022-01-18 13:12 (UTC)

Thanks @carbolymer. That seems to work perfectly now. Thank you so much for the quick fix (again!). Very much appreciated!

(I just pushed a fix for the zim.install checksum.)

carbolymer commented on 2022-01-18 11:28 (UTC)

Package should be fixed now.

Rhinoceros commented on 2022-01-16 22:55 (UTC)

No worries @carbolymer. Thanks for keeping at it!

carbolymer commented on 2022-01-16 19:15 (UTC)

Thanks @Rhinoceros for the information. I haven't had much time recently, I'll get back to the issue in a few days.

Rhinoceros commented on 2022-01-15 22:33 (UTC)

FWIW I previously installed r601.90de91a-1 perfectly fine, and the latest r606.bd765df-1 now fails to build.

It looks like upstream made some changes to the compilation process in the latest version 1.7.0. From the changelog, I'm not sure if some existing files also need to be removed.

Rhinoceros commented on 2022-01-12 04:42 (UTC)

It looks like upstream has changed the structure again, preventing this package from being built. ${srcdir}/install/src/templates now contains only zimrc and zshrc, so line 42–45 of the PKGBUILD fails:

  rcfiles=('zshenv' 'zshrc' 'zlogin' 'zimrc')
  for entry in "${rcfiles[@]}"; do
    cp -L "${srcdir}/install/src/templates/${entry}" $ZIM_TPL_DIR
  done

with zshenv and zlogin now missing. I'm don't understand the installation process enough to know how this changes things, and I can see that zlogin is used later in the PKGBUILD.

Rhinoceros commented on 2021-11-06 23:06 (UTC)

@carbolymer you likely saw it already, but just in case, upstream made some changes that might need this PKGBUILD to be modified.

Rhinoceros commented on 2021-09-30 07:04 (UTC)

Very strange. Originally it built fine on one of my systems, and another had the problem. However, when I tried to rebuild on the original system, it failed the second time. I also realised my minimal example was in zsh, but even testing with a clean bash shell using env -i bash --norc --noprofile, I still get the 1 exit code.

Thanks for the fix and the add.

carbolymer commented on 2021-09-30 06:57 (UTC)

@Rhinoceros, that's weird. I don't have this error, nor your minimal example with chmod and foo give me an error. I'm getting return code 0 even in bash. I've included your alternative chmod for the sake of compatibility.

Rhinoceros commented on 2021-09-29 11:16 (UTC)

Thanks for the fix.

I've run into another problem, which prevents the package from building:

patching file zimfw.zsh
Hunk #2 succeeded at 62 (offset 1 line).
Hunk #3 succeeded at 95 (offset 1 line).
==> ERROR: A failure occurred in package().
    Aborting...

It seems that the final chmod command has a non-zero exit code because of the symlinks at pkg/zsh-zim-git/usr/lib/zim/modules/zsh-syntax-highlighting/highlighters/*/README.md. Apparently chmod -R with symlinks fails!

$ mkdir dir
$ touch dir/foo
$ ln -s foo dir/bar
$ chmod -R u+rX,g+rX,o+rX dir
mode of 'dir' retained as 0755 (rwxr-xr-x)
neither symbolic link 'dir/bar' nor referent has been changed
mode of 'dir/foo' retained as 0644 (rw-r--r--)
$ echo $?
1

Weirdly I don't think this occurred all the time when building the package. Anyway, I managed to fix it by replacing the final chmod line with a command to ignore symlinks:

find "${ZIM_HOME}" ! -type l -execdir chmod u+rX,g+rX,o+rX {} \;

Rhinoceros commented on 2021-09-21 06:33 (UTC)

Upstream changed surrounding lines again. Here is an updated zimfw.zsh.patch.

--- zimfw.zsh   2021-09-21 16:26:34.034179638 +1000
+++ zimfw.zsh   2021-09-21 16:30:58.546504098 +1000
@@ -53,10 +53,6 @@

 _zimfw_build_init() {
   local -r ztarget=${ZIM_HOME}/init.zsh
-  # Force update of init.zsh if it's older than .zimrc
-  if [[ ${ztarget} -ot ${ZDOTDIR:-${HOME}}/.zimrc ]]; then
-    command mv -f ${ztarget}{,.old} || return 1
-  fi
   _zimfw_mv =(
     print -R "zimfw() { source ${ZIM_HOME}/zimfw.zsh \"\${@}\" }"
     print -R "zmodule() { source ${ZIM_HOME}/zimfw.zsh \"\${@}\" }"
@@ -65,16 +61,13 @@
     if (( ${#_zfunctions} )) print -R 'autoload -Uz '${_zfunctions#${~zpre}}
     print -R ${(F)_zcmds#${~zpre}}
   ) ${ztarget}
+  chmod -R u+rX,g+rX,o+rX "${ZIM_HOME}" &>/dev/null
 }

 _zimfw_build_login_init() {
   # Array with unique dirs. ${ZIM_HOME} or any subdirectory should only occur once.
   local -Ur zscriptdirs=(${ZIM_HOME} ${${_zdirs##${ZIM_HOME}/*}:A})
   local -r zscriptglob=("${^zscriptdirs[@]}/(^*test*/)#*.zsh(|-theme)(N-.)") ztarget=${ZIM_HOME}/login_init.zsh
-  # Force update of login_init.zsh if it's older than .zimrc
-  if [[ ${ztarget} -ot ${ZDOTDIR:-${HOME}}/.zimrc ]]; then
-    command mv -f ${ztarget}{,.old} || return 1
-  fi
   _zimfw_mv =(
     print -Rn "() {
   setopt LOCAL_OPTIONS CASE_GLOB EXTENDED_GLOB
@@ -101,6 +94,7 @@
 } \"\${@}\"
 "
   ) ${ztarget}
+  chmod -R u+rX,g+rX,o+rX "${ZIM_HOME}" &>/dev/null
 }

 _zimfw_build() {

carbolymer commented on 2021-08-10 06:45 (UTC)

@Rhinoceros, thanks for the fix! I've updated the package (I've also removed patch file copying as it's really not needed).

Rhinoceros commented on 2021-07-28 06:49 (UTC)

Oops, my mistake; I got confused. Upstream just modified surrounding lines. Here is an updated zimfw.zsh.patch that works.

--- zimfw.zsh   2021-07-28 16:45:25.000000000 +1000
+++ zimfw.zsh   2021-07-28 16:45:25.000000000 +1000
@@ -52,26 +52,19 @@

 _zimfw_build_init() {
   local -r ztarget=${ZIM_HOME}/init.zsh
-  # Force update of init.zsh if it's older than .zimrc
-  if [[ ${ztarget} -ot ${ZDOTDIR:-${HOME}}/.zimrc ]]; then
-    command mv -f ${ztarget}{,.old} || return 1
-  fi
   _zimfw_mv =(
     print -R "zimfw() { source ${ZIM_HOME}/zimfw.zsh \"\${@}\" }"
     if (( ${#_zfpaths} )) print -R 'fpath=('${_zfpaths:A}' ${fpath})'
     if (( ${#_zfunctions} )) print -R 'autoload -Uz '${_zfunctions}
     print -R ${(F)_zcmds}
   ) ${ztarget}
+  chmod -R u+rX,g+rX,o+rX "${ZIM_HOME}" &>/dev/null
 }

 _zimfw_build_login_init() {
   # Array with unique dirs. ${ZIM_HOME} or any subdirectory should only occur once.
   local -Ur zscriptdirs=(${ZIM_HOME} ${${_zdirs##${ZIM_HOME}/*}:A})
   local -r zscriptglob=("${^zscriptdirs[@]}/(^*test*/)#*.zsh(|-theme)(N-.)") ztarget=${ZIM_HOME}/login_init.zsh
-  # Force update of login_init.zsh if it's older than .zimrc
-  if [[ ${ztarget} -ot ${ZDOTDIR:-${HOME}}/.zimrc ]]; then
-    command mv -f ${ztarget}{,.old} || return 1
-  fi
   _zimfw_mv =(
     print -Rn "() {
   setopt LOCAL_OPTIONS CASE_GLOB EXTENDED_GLOB
@@ -98,6 +91,7 @@
 } \"\${@}\"
 "
   ) ${ztarget}
+  chmod -R u+rX,g+rX,o+rX "${ZIM_HOME}" &>/dev/null
 }

 _zimfw_build() {

Rhinoceros commented on 2021-07-19 10:00 (UTC)

package() is failing for me.

patching file zimfw.zsh
Hunk #2 FAILED at 66.
Hunk #3 succeeded at 95 (offset -1 lines).
1 out of 3 hunks FAILED -- saving rejects to file zimfw.zsh.rej

Looks like this part of zimfw.zsh.patch is no longer needed, as upstream has already incorporated it:

-  # Force update of init.zsh if it's older than .zimrc
-  if [[ ${ztarget} -ot ${ZDOTDIR:-${HOME}}/.zimrc ]]; then
-    command mv -f ${ztarget}{,.old} || return 1
-  fi

(Also, out of interest, why do you copy the patch before applying it, then delete it? You could always just apply it where it is.)

carbolymer commented on 2021-01-26 17:24 (UTC)

@Rhinoceros, thanks for debugging and reporting it here! You're right, it is imported twice. I've removed unnecessary line from zshrc:

source ${ZIM_HOME}/init.zsh &>/dev/null

In my opinion this /usr/lib/zim/templates/zshrc works fine, I took it from zimfw repo (which recommends it for enabling zim).

Rhinoceros commented on 2021-01-25 06:14 (UTC)

Ah, so modules are being sourced twice because /etc/zsh/zshrc contains two lines

source ${ZIM_HOME}/templates/zshrc &>/dev/null
source ${ZIM_HOME}/init.zsh &>/dev/null

but /usr/lib/zim/templates/zshrc also contains source ${ZIM_HOME}/init.zsh. I'm not sure if this is an error from upstream? I also had a look through /usr/lib/zim/templates/zshrc, and it had a bunch of options in there that I overwrite in ~/.zshrc anyway. It also contained the very nasty HIST_IGNORE_ALL_DUPS, which wrecked my history file! I just removed the first line in /etc/zsh/zshrc and replaced it with

source ${ZIM_HOME}/zimfw.zsh init -q &>/dev/null

This seems to work fine.

Rhinoceros commented on 2021-01-24 07:03 (UTC)

No worries @carbolymer. Thanks for the hint. That works great! One other thing is still bugging me… any idea how to stop (e.g.) /usr/lib/zim/modules/environment/init.zsh being sourced twice with each new terminal?

carbolymer commented on 2021-01-22 07:50 (UTC)

@Rhinoceros Sorry, I've made a mistake in the patch, I forgot to make chmod run recursively. Now the rights should be correct. Regarding adding/removing modules, you can add/remove them to /etc/zsh/zimrc. I've added steps to my pinned comment.

Rhinoceros commented on 2021-01-22 07:09 (UTC) (edited on 2021-01-24 07:09 (UTC) by Rhinoceros)

Ugh… I've spent another few hours trying to figure out how to specify what modules are loaded. At the moment, some are loaded twice. e.g. edit /usr/lib/zim/modules/environment/init.zsh and put echo foo at the top, and a new terminal will show foo twice. I also want to disable some, e.g. git. I couldn't see zmodule git in any of the installed files, but there are a few references to git in /usr/lib/zim/init.zsh. Just to test, I removed these references, then did the mandatory touch ~/.zimrc as before. I also noticed that /usr/lib/zim/init.zsh is owned by root:root with 600 permissions, so to avoid errors I had to make it 644 instead (is that a bug?). This seemed to work, in that the git module was no longer active.

1) What is the best way to load/unload modules?

2) Is the fact that /usr/lib/zim/init.zsh is not user-readable correct?

Rhinoceros commented on 2021-01-15 07:42 (UTC)

Thanks again @carbolymer for your continued assistance. I can appreciate that this is a very fiddly package, so thanks for staying with it.

Your suggestion for zshmarks works perfectly. This command modifies /usr/lib/zim/init.zsh. I feel like it may be better to modify a user-owned file, but I think by default there is only one init.zsh. I can see /usr/lib/zim/init.zsh is sourced by /etc/zsh/zshrc. I wonder if a better solution is for users to copy init.zsh to somewhere in their home directory, with /etc/zsh/zshrc sourcing this file instead? I guess since /etc/zsh/zshrc is in the PKGBUILD's backup array, users can always do this themselves. Or is it better for the PKGBUILD to do this? I haven't delved too deeply in it, but a possible positive of making init.zsh (and other things?) is that there will be no errors? But a possible negative is that zimfw might try to automatically update (although this could be disabled by default).

carbolymer commented on 2021-01-13 18:15 (UTC) (edited on 2021-01-13 18:16 (UTC) by carbolymer)

I've cloned zshmarks to /usr/lib/zim/modules then added zmodule zshmarks to /etc/zsh/zimrc, then sudo zsh then zimfw install && zsh and it works.

The command which causes

mv: cannot move '/usr/lib/zim/init.zsh' to '/usr/lib/zim/init.zsh.old': Permission denied

is zrecompile which is necessary I think. The only workaround is to silence this error.

I've added a patch for part of force update you suggested though, thanks for the hint!

Rhinoceros commented on 2021-01-13 03:22 (UTC)

Another bit of weirdness. After updating the package, I have to touch ~/.zimrc in order for it to be sourced in the future at all. It might be related to line 55 of /usr/lib/zim/zimfw.zsh?

  # Force update of init.zsh if it's older than .zimrc

This might need to be patched for installation by a package manager.

Also, regarding the general suppression of error messages, I wonder if a cleaner way would be to patch out the specific command that causes the error

mv: cannot move '/usr/lib/zim/init.zsh' to '/usr/lib/zim/init.zsh.old': Permission denied

FWIW I only ever get this one error. I had a brief look, and I think the command might also be in /usr/lib/zim/zimfw.zsh.

Rhinoceros commented on 2021-01-12 09:31 (UTC)

Thanks again @carbolymer! Manually sourceing powerlevel10k works perfectly. By your GitHub link, did you mean this alternative would require installing powerlevel10k without pacman? I'd much prefer for the package manager to keep everything updated, so if so I'll just use the manual way instead.

On a related note, might you have any suggestions for how to get zshmarks working? I'm the maintainer. Previously I just symlinked the entire project directory into /usr/lib/zim/modules/zshmarks, then edited ~/.zimrc to add zshmarks to the zmodules array, but this no longer works. I tried zmodule zshmarks instead, but this also fails.

Actually, the post after your link suggests this should work, but it doesn't seem to be working for me.

carbolymer commented on 2021-01-12 08:25 (UTC) (edited on 2021-01-12 08:38 (UTC) by carbolymer)

@Rhinoceros, thanks for the hint. I've added it to the package.

I've checked powerlevel10k, and it works fine without zim interaction i.e. I've installed aur package and added

source /usr/share/zsh-theme-powerlevel10k/powerlevel10k.zsh-theme

to /etc/zsh/zshrc below lines sourcing zim.

If you would like to use zim, this also works for me: https://github.com/zimfw/zimfw/issues/368#issuecomment-631520836 but you need to add this zmodule to /etc/zsh/zimrc (which is symlinked by ~root/.zimrc) and then do zimfw install

Rhinoceros commented on 2021-01-12 07:05 (UTC)

Thanks so much @carbolymer! This seems to work well, although I had some problems with my old ~/.zimrc. I had to remove the error suppression in /etc/zsh/zshrc to figure out the problem.

Do you know what the syntax is now to use pacman-installed modules? In the past I linked the files, e.g.

# ln -s /usr/share/zsh-theme-powerlevel10k /usr/lib/zim/modules/prompt/external-themes/powerlevel10k
# ln -s /usr/share/zsh-theme-powerlevel10k/powerlevel10k.zsh-theme /usr/lib/zim/modules/prompt/functions/prompt_powerlevel10k_setup

then put zprompt_theme='powerlevel10k' into ~/.zimrc, but this now fails silently. I tried zmodule powerlevel10k instead, but this fails with

x /home/rhinoceros/.zimrc:34:powerlevel10k: Not installed. Run zimfw install to install.
Failed to source /home/rhinoceros/.zimrc

I also had one minor suggestion. Instead of using + as a sed delimiter, which will break if this character is in filenames, you could instead use parameter expansion to prevent this limitation.

(Also, there was some discussion here regarding packaging that you might like to contribute to.) Thanks again!

carbolymer commented on 2021-01-11 21:41 (UTC) (edited on 2021-01-22 07:46 (UTC) by carbolymer)

Ugh, it was a PITA to create this package. Please note that errors are silenced, so if you have any issues with zim, remove &>/dev/null from your /etc/zshrc - https://aur.archlinux.org/cgit/aur.git/tree/zshrc?h=zsh-zim-git&id=5a378e94d516c57d39629de545b78b0f020d86a4

I had to do it this way: $ZIM_HOME is only writable by root and zim constantly tries to update & recompile itself (=write to $ZIM_HOME), which results in permission errors when starting zsh as a normal user.

If you want to add/remove a module:

  1. Add a respective zmodule in /etc/zsh/zimrc
  2. Run as root: zimfw install && zsh

eschwartz commented on 2021-01-06 02:11 (UTC)

@mattia,

I can't even call these changes anything other than outright malware. Force reverting and purging from history, disowning, do not do this sudo curl | zsh nonsense ever again, do not rewrite PKGBUILDs to not actually package anything, do not download unchecksummed sources outside of source=() and mysteriously execute them like this.

Rhinoceros commented on 2021-01-03 22:44 (UTC)

@mattia makepkg really shouldn't require sudo. It should be capable of creating a package in a user-owned location. In any case, I'm not sure what the purpose of this sudo is in the PKGBUILD. It's just for the curl right? Why would that need sudo? Finally, it looks like the PKGBUILD attempts to directly run install.zsh from upstream. Doesn't that immediately attempt to install zim rather than place it into the pkgdir? Running makepkg certainly shouldn't be creating anything at /usr/lib/zim!

FWIW there's been an extensive discussion upstream on how to fix this broken package, but there was no resolution.

commented on 2021-01-03 16:51 (UTC)

@carbolymer now it should go, I forgot a sudo. Thanks so much for the warning

carbolymer commented on 2021-01-03 12:25 (UTC) (edited on 2021-01-03 12:25 (UTC) by carbolymer)

this package is broken

mkdir: cannot create directory ‘/usr/lib/zim’: Permission denied

x Could not download the Zim script to /usr/lib/zim/zimfw.zsh

Rhinoceros commented on 2020-02-22 22:44 (UTC)

FWIW I agree with @bus. If I no longer have an interest in maintaining a package, I orphan it. This shows users that there is no one actively maintaining it, and may inspire others to adopt it. Hence the previous adoption drives. If we don't know which are unmaintained, then we can't adopt them. I also don't view it as my responsibility to protect against future "malicious intents". (Also, despite your earlier response, you aren't exactly responding to the "request" to update the package! And the fix is certainly actionable, at least in theory.)

ishitatsuyuki commented on 2020-02-19 14:26 (UTC)

Well, I could say either way, but the out-of-date flagging isn't really actionable. If you're not going to contribute, then I don't really see any point on discussing this meta-issue.

bus commented on 2020-02-19 14:18 (UTC) (edited on 2020-02-19 14:19 (UTC) by bus)

@ishitatsuyuki I suggest you read the flagging page: "Flagging this package should only be done if the sources moved or changes in the PKGBUILD are required because of recent upstream changes". The package does not build because upstream changed, it's literally out of date by definition.

Also, I don't think that's a correct interpretation of orphaning. It's very commonly done voluntarily when people have no desire to work on their packages, which you said you don't. You're thinking of assisted orphaning via requests, which is performed when the maintainer is not responding.

ishitatsuyuki commented on 2020-02-19 13:34 (UTC)

@bus Do not flag packages out-of-date for any reasons other than versions (which means that you should never flag a VCS package)!

I'm not going to let some random person take over this package without verifying they don't have malicious intents. Orphaning is only required when the maintainer (is intending to) no longer responds to any comments or requests.

Rhinoceros commented on 2020-01-10 12:15 (UTC)

Ah yes true. Thanks for the reply. I'll have a bit of a play and see if I can work out how to install it at a system level first, but yes, I might end up the same way.

ishitatsuyuki commented on 2020-01-10 12:12 (UTC)

I just switched to a user level install and I'm fine with that since I'm the only one using the computer anyway.

And using a package is not the only way to update, you could just set up a cron job or whatever.

Rhinoceros commented on 2020-01-10 12:09 (UTC) (edited on 2020-01-10 12:09 (UTC) by Rhinoceros)

Fair enough. TBH I thought about creating the stable zsh-zim package, but a brief look at upstream confused me. Out of interest, will you continue to use zsh-zim? And if so, will you just install it at a user-level?

EDIT: that's not my preference because I'd never remember to update it.

ishitatsuyuki commented on 2020-01-10 06:36 (UTC)

Since the upstream doesn't like zimfw getting packaged for global installation, and porting seems to be harder with the latest template changes, I'm going to stop maintaining this package. Contributions are still welcome.

Rhinoceros commented on 2020-01-08 06:17 (UTC)

This no longer builds for me.

==> Starting package()...
cp: cannot create regular file '/tmp/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/templates/zshrc': No such file or directory

It looks like the subdirectory templates is no longer present upstream.

Also, regarding the previous comments, there's now a stable release out: https://github.com/zimfw/zimfw/releases

ishitatsuyuki commented on 2019-09-29 12:00 (UTC)

Since zimfw does not have any releases at this point, I don't see any point in doing that.

bbaserdem commented on 2019-09-28 17:29 (UTC)

As a git package, I believe the proper way of doing this package is have it conflict and replace zsh-zim; so when there is a stable release there can be a git package and a release package.

ishitatsuyuki commented on 2019-02-09 12:16 (UTC)

I don’t think that helps in any way. I already do that in the install file, and all you need is a rebuild and install of zsh-zim-git.

carbolymer commented on 2019-02-09 12:11 (UTC)

After each update, zsh floods the console with following error message: https://pastebin.com/A91n9eBR. The solution is to invoke:

sudo find /usr/lib/zim/modules -iname "*.zwc" -exec rm -f {} \;

and reinstal zsh-zim-git. I think this should be added to the prepare() in PKGBUILD.

ishitatsuyuki commented on 2017-10-22 01:43 (UTC)

A big thanks for investigating: the zimrc issue is fixed. * ZIM_HOME is set in /etc/zsh/zshrc, and that's in the "backup" list so you may have to manually overwrite. * I think the zwc issues should fix after a reinstall (with correct zshrc).

carbolymer commented on 2017-10-21 22:25 (UTC)

Oh boy, this last update really screwed up my ZSH. I had to fix following things: * ZIM_HOME is set incorrectly to $HOME/.zim instead of /usr/lib/zim by /usr/lib/zim/init.zsh, despite using zshrc from this package * /usr/lib/zim/templates/zimrc is not sourced somehow - no additional modules are loaded and "No such module" errors visible. Quick fix, add: source /usr/lib/zim/templates/zimrc in /usr/lib/zim/init.zsh:15 * liquidprompt theme is not available (probably because /usr/lib/zimrc wasn't sourced) * zsh in tmux is spewing out "zcompare:zcompile:2: can't write zwc file" messages, quick fix: add &>/dev/null in /usr/lib/zim/templates/zlogin:16 I guess this should fix the errors observed by @vodi, @tembleking and @Shebang

ishitatsuyuki commented on 2017-10-21 04:45 (UTC)

- Do you see any errors? - What happens if you run `zsh --login`? I think it's something being wrong in /etc. Please check the files in the "backup" list of PKGBUILD. Another suspect is the precompilation went wrong. Uninstalling and reinstall (not update) will recreate a clean cache.

vodi commented on 2017-10-20 17:42 (UTC)

Hi! Detailed Problem description: * Had zsh-zim-git installed and running before 2017-10-18 * updated zsh-zim-git via `pacaur -Syu' * zim not loading when opening a new shell (e.g. prompt ist only `hostname%', C-r history search not working) * i don't have zim-related config in my home folder - so not "something in their config" * `source /etc/zsh/zshrc' does not change anything If you need any additional infos (e.g. logs? configs?) let me know, I'm pleased to provide it. If you have any suggestions how to get zim running, I'm open to try it. Thank you for your effort maintaining this package for us

Shebang commented on 2017-10-20 01:06 (UTC)

ishitatsuyuki and vodi, It is now working for me. I'm thinking vodi and tembleking may have something in their configs that is causing the issue. Thanks for updating so quickly ishitatsuyuki

ishitatsuyuki commented on 2017-10-19 04:20 (UTC)

Works for me. Explain your problem in detail.

vodi commented on 2017-10-18 16:40 (UTC)

Hi! I have the same problem as tembleking. I updated the zsh-zim-git package with pacaur and after that zim doesn't get loaded. I already tried uninstalling (/etc/zsh/zshrc was deleted) and reinstalling it, but it didn't work. If you need additional infos, let me know.

ishitatsuyuki commented on 2017-10-18 14:55 (UTC)

I have tested the new version extensively. How did it broke your installation? Please try resetting /etc/zsh/zshrc (e.g. by deleting it and reinstall).

tembleking commented on 2017-10-18 14:48 (UTC)

Last AUR commit broke the zim instalation completely: https://aur.archlinux.org/cgit/aur.git/commit/PKGBUILD?h=zsh-zim-git&id=f06ce5a11f1ac071c306bf54f1f51e225f530428 I tried to install the package with the previous AUR commit: https://aur.archlinux.org/cgit/aur.git/commit/PKGBUILD?h=zsh-zim-git&id=c082f63fde8d4ff5e274e565ffbd6aae3210e41d And now it's working fine.

ishitatsuyuki commented on 2017-10-18 04:01 (UTC)

Updated. Enjoy.

Shebang commented on 2017-10-18 00:27 (UTC)

I decided to remove the package and then reinstall it to get the latest code from git (if there's a better way to do this, please do tell). I'm now getting this whenver I open a terminal / start zsh: No such module "directory". No such module "environment". No such module "git". No such module "git-info". No such module "history". No such module "input". No such module "utility". No such module "meta". No such module "custom". No such module "syntax-highlighting". No such module "history-substring-search". No such module "prompt". No such module "completion". /usr/lib/zim/templates/zlogin:41: no matches found: /home/steven/.zim/modules/custom/**/^(README.md|*.zwc)(.)

gdiscry commented on 2017-09-28 08:15 (UTC)

I have zim installed only as a package (nothing in $HOME) and have just updated the package (I was on r326.537f076). There are a few issues with the /etc/zsh/* files generated by the package. My fixes below are specific to my use case. They are probably not enough when the user also has a local install. The first one is "/usr/lib/zim/templates/zlogin:41: no matches found: /home/georges/.zim/modules/custom/**/^(README.md|*.zwc)(.)" appearing when opening a new shell. This is caused by ZIM_HOME defaulting to ${HOME}/.zim (which doesn't exist in my case). I added "ZIM_HOME=/usr/lib/zim" at the beginning of /etc/zsh/zshrc before sourcing zim. However, it's not enough to solve the issue because "source /usr/lib/zim/templates/zshrc" resets ZIM_HOME. I simply deleted that line because the template does only two things: set ZIM_HOME and source ${HOME}/.zim/init.zsh (which doesn't exists) and zshrc already does "source /usr/lib/zim/init.zsh". Finally, /usr/lib/zim/templates/zlogin tries to compile a lot of files, which doesn't work with a simple user. My temporary fix is to open a login shell as root. I think that the templates do not fit the case of a system-wide install. We either need better templates or stop sourcing them. /etc/zsh/zshrc should set ZIM_HOME=/usr/lib/zim and stop sourcing the template (it already sources init.zsh) /etc/zsh/zlogin should also stop sourcing the template. Instead, build() in the PKGBUILD should directly call zcompile so that the compiled files are part of the package.

ariasuni commented on 2017-06-08 10:40 (UTC)

You should change `rsync -ar --exclude=.git $srcdir/$_gitname/ $pkgdir/usr/lib/zim` to `rsync -ar --exclude=.git* $srcdir/$_gitname/ $pkgdir/usr/lib/zim` in order to ignore `.github`, `.gitignore` and `.gitmodules` files.

TangledShoelace commented on 2017-01-23 14:48 (UTC)

`rsync` might have to be added as a dependency. Got an error: `.../zsh-zim-git/PKGBUILD: line 50: rsync: command not found`

Rhinoceros commented on 2017-01-23 11:04 (UTC)

Yep, I'm at 27cdd5cefa6f26d4bc57a8aa2d19d13db1db44bf. I've even been totally cleaning the repository with `git clean -dff` before `makepkg`. Hmmm… so it seems that `zsh -l` and `zsh --login` also create the same errors for me as tmux and tty. However, again, I get no problem with a "normal" shell, where I just have `/bin/zsh` defined in `/etc/passwd`.

ishitatsuyuki commented on 2017-01-23 10:58 (UTC)

Please make sure you're at 27cdd5c (AUR git), and used the -f option to rebuild the package (I didn't change the package revision, sorry). zsh -l (or --login) loads zlogin, which tries to precompile the files. tmux and tty also runs a login shell.

Rhinoceros commented on 2017-01-23 10:55 (UTC)

Did you mean with the one you pushed before my last comment, or have you forgotten to push a new one? I definitely pulled the last changes. I'm not sure what `zsh --login` does exactly. I can't find `--login` in `man zshall`. However, tmux *isn't* exactly the same. In a new terminal emulator, zsh loads fine with no warning. However, if I manually start `tmux`, then I get the errors as described. Actually, I get these same errors if I log into a tty shell, so you might be able to reproduce with that too.

ishitatsuyuki commented on 2017-01-23 10:39 (UTC)

I'm pretty confident with the current one, have you really fetched the latest changes? I cannot reproduce anymore. tmux is basically a login shell, zsh --login does the same thing.

Rhinoceros commented on 2017-01-22 09:52 (UTC)

This time when upgrading, I get (1/1) reinstalling zsh-zim-git [##############] 100% /usr/lib/zim/templates/zlogin:24: no matches found: /root/.zcomp^(*.zwc)(.) Then I still get the same errors as before in tmux. Are you testing (and seeing errors) in tmux too?

ishitatsuyuki commented on 2017-01-22 08:27 (UTC)

Sorry, I was testing to roughly. I feel stupid now :P @Rhinoceros, please try again, this one should finally behave correctly.

Rhinoceros commented on 2017-01-22 08:03 (UTC)

This time there is definitely no error on upgrading, but I still get the error in tmux. Thanks again for trying, though. Does anyone know exactly what the error implies? It's not like I use tmux all the time anyway…

ishitatsuyuki commented on 2017-01-22 06:12 (UTC)

@Rhinoceros, I hope this time works for you.

Rhinoceros commented on 2017-01-21 21:19 (UTC)

Oh, I just upgraded again, and now I get the following error. I'm not sure if I actually got it before and didn't notice. (1/1) upgrading zsh-zim-git [############] 100% zsh: no matches found: /root/.zcomp^(*.zwc)(.) error: command failed to execute correctly

Rhinoceros commented on 2017-01-21 11:13 (UTC)

No worries at all! Thank you for diagnosing it. I very much appreciate your efforts.

ishitatsuyuki commented on 2017-01-21 11:11 (UTC)

Oh, I see. Please wait for some time while I diagnose that. Sorry for the inconvenience.

Rhinoceros commented on 2017-01-21 09:30 (UTC)

Yes, I updated to the new PKGBUILD, then tested. What exactly do you mean "as root"? Do you mean after `sudo -i`? If so, then I just get a single line as follows. zsh: no matches found: /root/.zcomp^(*.zwc)(.)

ishitatsuyuki commented on 2017-01-21 09:12 (UTC)

@Rhinoceros, please make sure that you have updated to today's PKGBUILD. If you have already updated, please run the following as root and tell me if you get any suspicious output: sed 's/\&!//' /usr/lib/zim/templates/zlogin | zsh

Rhinoceros commented on 2017-01-21 09:01 (UTC)

@ishitatsuyuki, was that a reply to my comment? If so, that didn't seem to make any difference. N.B. I'm talking about messages at every new tmux session, not just during the zsh-zim-git install script.

ishitatsuyuki commented on 2017-01-21 07:49 (UTC)

Should be better now, enjoy!

Rhinoceros commented on 2016-06-30 00:51 (UTC)

FWIW I tried installing this again, and it now works fine to start. However, when I start a tmux session, I get flooded with the same `zcompare:zcompile:2: can't write zwc file` errors. I also noticed that gavsiu posted upstream, and the dev again suggested not to install in a root-only directory. It's a pity, as I'll never remember to update though. :(

ishitatsuyuki commented on 2016-06-12 04:43 (UTC)

@gavsiu: please check if you have zsh stuffs in /root. Also make sure the package is installed without any conflict. Well, it should be loaded as long as global zshrc exists...

gavsiu commented on 2016-06-11 21:58 (UTC) (edited on 2016-06-11 22:09 (UTC) by gavsiu)

@ishitatsuyuki: Sorry, how do I check that? I've just installed zsh and only have a .zshrc in my user home folder. I haven't modified anything in /etc. I just installed zim using the directions from the Git readme and the problem is not there. I'd like to use this package instead if the problem doesn't occur.

ishitatsuyuki commented on 2016-06-11 06:35 (UTC)

@gavsiu: Can you check if root has a custom zsh setup? The script will break if root doesn't load the global installed zshrc.

gavsiu commented on 2016-06-11 06:17 (UTC)

I'm getting the same issue now even though it's supposedly fixed. zcompare:zcompile:2: can't write zwc file: /usr/lib/zim/modules/*.zwc There are 123 lines and I substituted what was different on each line with a * I've recently installed this on my unencrypted Arch install and did not have any issues. Although I cannot remember if I used the AUR or straight from GitHub. I reinstalled on a different drive with FDE and this package is giving me that error. No .zimrc, copied my old .zimrc, copied my old .zim folder because for some reason I had one and I don't on the new install... nothing worked. This led me to believe maybe I didn't use this package.

ishitatsuyuki commented on 2016-04-25 09:01 (UTC)

@Rhinoceros: Latest PKGBUILD works fine for me. I could reproduce your problem if used old one. BTW, I think init.zsh will source .zimrc...

Rhinoceros commented on 2016-04-25 07:38 (UTC)

@ishitatsuyuki I'm not sure what that fixed exactly? I'm still getting the same errors @Brottweiler, i.e. the install and `can't write zwc file` errors. Ah, good point. So /etc/zsh/zshrc runs, calling /etc/zsh/zimrc (where the zmodules are defined), then /usr/lib/zim/init.zsh. Between these two source statements, I could add a line manually overwriting the zmodules. That's probably fine then. (Assuming I can work out the problems with the system-wide install.)

ishitatsuyuki commented on 2016-04-22 11:01 (UTC)

@Brottweiler CC @Rhinoceros Fix uploaded. @Rhinoceros: I'm not sure what you're going to do. You can change zim modules by modifying zimrc: that's loaded after global configuration and before initialization.

Rhinoceros commented on 2016-04-22 10:27 (UTC)

@Brottweiler Thanks for that. I can see from your comments on the Github issue that you are using a manual user-level install… I guess that's the only answer (and also fixes my other question). It's a pity we won't have automatic updates, though. @ishitatsuyuki However, /etc/zsh/zshrc will still run before ~/.zshrc, so although the ~/.zshrc will run later (and have "higher priority"), the shell still will run both versions… and somehow unload the modules defined in /etc/zsh/zshrc. I guess I could modify /etc/zsh/zshrc (which is in the backup array) to point to an alternative instead of /usr/lib/zim/templates/zimrc, but then this would miss any updates. Having said that, @Brottweiler's comments make me think that the idea of a system-wide install is not workable anyway.

ishitatsuyuki commented on 2016-04-22 09:08 (UTC)

@Rhinoceros: The expected way is to copy that to .zimrc (others work too), and modify it. Then it has higher priority than installed one.

Brottweiler commented on 2016-04-22 07:49 (UTC)

@Rhinoceros, Please read this https://github.com/Eriner/zim/issues/44

Rhinoceros commented on 2016-04-22 06:36 (UTC)

When I install, I get /usr/lib/zim/templates/zlogin:22: no matches found: /root/.zcomp^(*.zwc)(.) Also, this package makes zsh source `/usr/lib/zim/templates/zimrc` by default, which is where the modules are enabled. I wonder if you could include this file in the backups array. Then users could modify this, and it won't be over-written on updates.