No, thanks for the catch and cleanup, ft. closing this bug.

regards,
-mika-

Is there a good reason for keeping this one open?

Michael Prokop <mika@grml.org> has uploaded a package that may fix your bug.
Please test the package and inform the maintainer whether
version 0.3.41 of grml-etc-core works as intended or not.

Thank you

The changelog is attached below

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 02 Dec 2007 19:54:45 +0100
Source: grml-etc-core
Binary: grml-etc-core
Architecture: source all
Version: 0.3.41
Distribution: unstable
Urgency: low
Maintainer: Michael Prokop <mika@grml.org>
Changed-By: Michael Prokop <mika@grml.org>
Description: 
 grml-etc-core - core ecetera files for the grml system
Changes: 
 grml-etc-core (0.3.41) unstable; urgency=low
 .
   The big zsh update release.
 .
   [ Alexander Steinböck]
   * standarized the use of brackets - double instead of
     single ones - for test situations like if-clauses [thanks!]
     [Testing: issue354]
 .
   [ Michael Prokop ]
   * add alias 'g' for git
   * set modelines for vim according to new indenting policy
   * extend debbug() based on http://xana.scru.org/quanks/b-func.html
 .
   [ Frank Terbeck ]
   * several small cleanups by ft
   * patch bomb for unified indenting
   * introducing check_com() to check for the existence of commands
   * introducing more utility functions: xcat and xsource
     moving salias to utility functions
Files: 
 d3c81c2bd72cbbe10c653673f48a97d8 596 grml optional grml-etc-core_0.3.41.dsc
 0bcf6228302afe95efc9bbbd01b92469 91692 grml optional grml-etc-core_0.3.41.tar.gz
 76d3fb54c808bf971d77d634929cead5 93368 grml optional grml-etc-core_0.3.41_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHXGYK2N9T+zficugRAkc0AJ44Jw8jQO116cLYYR/Kr1jtQiw8rgCeK6OI
YhyOkVrQ8VGdVCEVTV17eR8=
=zcIO
-----END PGP SIGNATURE-----

Please apply this one, too.
I think it makes perfect sense.

[...]
> # Parent  334ccd4978ac4d7e4f774bbdb8b876c7570a0d81
> Only read .zshrc.global if $ZSHRC_GLOBAL_HAS_BEEN_READ is not set yet
> 
> diff -r 334ccd4978ac -r 7fdd3d007553 etc/skel/.zshrc
> --- a/etc/skel/.zshrc	Fri Dec 07 08:17:38 2007 +0100
> +++ b/etc/skel/.zshrc	Fri Dec 07 08:31:46 2007 +0100
> @@ -15,7 +15,9 @@
[...]
> -   [[ -r "${HOME}/.zshrc.global" ]] && source "${HOME}/.zshrc.global"
> +    [[ -z "$ZSHRC_GLOBAL_HAS_BEEN_READ" ]]  \
> +    && [[ -r "${HOME}/.zshrc.global" ]]     \
> +        && source "${HOME}/.zshrc.global"
>  
>  # }}}

Patch appended. Again. (I hate my unstable ppp connection these days).

Regards, Frank

Michael Prokop <bts@bts.grml.org>:
> > Thanks for your work, works really fine. The only remaining issue is the 
> > 'xsource' stuff we (ft + me) were talking about via ICQ. Keeping the bugreport 
> > open therefore.

Okay, here's a fix. It's very simple and will not change anything for
anyone. I'll comment on the export and append a clean one:

[...]
> -if type xsource &>/dev/null ; then
> -   xsource "${HOME}/.zshrc.global"
> -else
> -   . "${HOME}/.zshrc.global"
> -fi
> +
> +# Note, that xsource() is defined in the global file, so here,
> +# we will have to do the sourcing manually for once:
> +
> +   [[ -r "${HOME}/.zshrc.global" ]] && source "${HOME}/.zshrc.global"
> +

Doing this manually for '.zshrc.global' doesn't hurt too much, and it
solves the case.

[...]
>  if [[ -z "$ZSHRC_GLOBAL_HAS_BEEN_READ" ]] ; then
> -    print 'Warning: global zsh config has not been read'>&2
> +    print 'Warning: global zsh config has not been read.' >&2
> +    print '         prepare for possible errors!'         >&2

Adding further information to the warning message. Because code, that
depends on stuff in the global file will make that code fail.

[...]
> -if type xsource &>/dev/null ; then
> -    xsource "${HOME}/.zshrc.local"
> -else
> -    . "${HOME}/.zshrc.local"
> -fi
> +xsource "${HOME}/.zshrc.local"

If the global file was sourced (which it *really* *should*), we can
depend on code from it unconditionally here. So we should just do it,
and expect user's who use the setup on non-grml-systems to follow the
instructions from the reference card (which we do not need to change
with this solution).

Comments? .o( Though, I really think this is the way to go. )

Regards, Frank

Thanks for your work, works really fine. The only remaining issue is the 
'xsource' stuff we (ft + me) were talking about via ICQ. Keeping the bugreport 
open therefore.

Frank Terbeck <ft@bewatermyfriend.org>:
[...]
> Note, that I am still troubled about the use of 'type' instead of
> 'which'. Could someone enlighten me about this?
[...]

Okay, here we go for this one.
See appended diff.

Regards, Frank

* Alexander Steinböck <bts@bts.grml.org> [20071204 17:50]:
> Alexander Steinböck added the comment:
> * Frank Terbeck <bts@bts.grml.org> [2007-12-04 13:25]:

> > There is one issue.
> > "if [[ -x $(type aterm) ] ; then"

> This happend on purpose and has been a patch by Michael.

Yeah, my bullshit. :-/ Sorry for that. (Wasn't a problem of
mercurial, instead a false braindump @ mika)

regards,
-mika-

* Frank Terbeck <bts@bts.grml.org> [2007-12-04 13:25]:

> There is one issue.
> "if [[ -x $(type aterm) ] ; then"
This happend on purpose and has been a patch by Michael.

,----[ % hg glog -l 2 ]-
| @  changeset:   329:80819289a2a6
| |  tag:         tip
| |  user:        Michael Prokop <mika@grml.org>
| |  date:        Mon Dec 03 23:00:48 2007 +0100
| |  summary:     Apply patch by z3ttacht regarding issue354
| |
| o  changeset:   328:ab20fe3dee9b
| |  user:        Michael Prokop <mika@grml.org>
| |  date:        Mon Dec 03 22:18:53 2007 +0100
| |  summary:     zsh: replace $(which ...) with $(type ...)
`----

> Anyway, the attached patch fixes this problem and does further
> cleanups. Like == instead of =, -eq for integer comparison and
> doing:
Good deal! Missed these completely. (o;

HTH,
z3ttacht

* Frank Terbeck <bts@bts.grml.org> [2007-12-04 13:25]:

This happend on purpose and has been a patch by Michael.

`----

Good deal! Missed these completely. (o;

HTH,
z3ttacht

[...]
> > I set the bugreport to 'testing' and didn't yet upload a package
> > yet, please send me a short ACK if you think it's really OK. :)

Here we go:

There is one issue.
"if [[ -x $(type aterm) ] ; then"

Alexander's patch involved the old $(which aterm) solution and does
*not* include this problem. It is however in our hg repo:

Alexander's patch (which I downloaded from the bts):
[snip]
-     if [ -x $(which aterm) ] ; then
-        isutfenv && [ -n "$LANG" ] && alias aterm="LANG=${LANG/(#b)(*)[.@]*/$match[1].iso885915} luit aterm"
+     if [[ -x $(which aterm) ]] ; then
+        isutfenv && [[ -n "$LANG" ]] && alias aterm="LANG=${LANG/(#b)(*)[.@]*/$match[1].iso885915} luit aterm"
[snap]

Our repo (the changeset that incorporates the patch):
[snip]
- if [ -x $(type aterm) ] ; then
- isutfenv && [ -n "$LANG" ] && alias aterm="LANG=${LANG/(#b)(*)[.@]*/$match[1].iso885915} luit aterm"
+ if [[ -x $(type aterm) ] ; then
+ isutfenv && [[ -n "$LANG" ]] && alias aterm="LANG=${LANG/(#b)(*)[.@]*/$match[1].iso885915} luit aterm"
[snap]

Mercurial bug?
Anyway, the attached patch fixes this problem and does further
cleanups. Like == instead of =, -eq for integer comparison and doing:

[snip]
-  if [[ $foobar == baz ]]
-  then
+  if [[ $foobar == baz ]] ; then
[snap]

Note, that I am still troubled about the use of 'type' instead of
'which'. Could someone enlighten me about this?

Also, if the above issue *is* a mercurial problem, that would make me
kind of nervous, too.

Comments?

Regards, Frank

[...]
> 
> > I skimmed through it and saw nothing suspicious.
> 
> me2, applied the patch and pushed it.
> 
> > I'll look at it in more detail tomorrow afternoon (for certain values
> > of $TZ).
> 
> I set the bugreport to 'testing' and didn't yet upload a package
> yet, please send me a short ACK if you think it's really OK. :)

Will do.

Regards, Frank

I tried to standarize the use of indention to the one mostly used as
well. Mostly older functions, e.g. mkiso(), used wider indention
than the other ones.

Furthermore I attempted to sort the aliases of the power completion
by fields of application.

* Frank Terbeck [20071203 22:57]:
> Alexander Steinböck:

[...]

> Nice one.

ACK!

> I skimmed through it and saw nothing suspicious.

me2, applied the patch and pushed it.

> I'll look at it in more detail tomorrow afternoon (for certain values
> of $TZ).

I set the bugreport to 'testing' and didn't yet upload a package
yet, please send me a short ACK if you think it's really OK. :)

Thanks!

regards,
-mika-

Alexander Steinböck <bts@bts.grml.org>:
> New submission from Alexander Steinböck <stone_henge@web.de>:
> 
> Standarized the use of brackets - double instead of single ones -
> for test situations like if-clauses.
> For info, see http://zsh.dotsrc.org/Guide/zshguide02.html#l8 , last
> paragraph.
> Furthermore several cases of 'if [[..]]; then` where changed to the
> otherwise used form 'if [[..]] ; then`.
> Oneliners used:
> % sed -i 's,\]\;\( then\),\] ;\1,' etc/{skel,zsh}/.#z*
> % sed -i 's,[^\["]\(\[ \+[-!"$]\+\), [\1,g;s,\( ]\)\([ ;]\+\),\1]\2,g' etc/{skel,zsh}/.#z*
> 
> I checked the result several times. I really hope I did not miss any
> false positive.

Nice one.

I skimmed through it and saw nothing suspicious.
I'll look at it in more detail tomorrow afternoon (for certain values
of $TZ).

Regards, Frank

Standarized the use of brackets - double instead of single ones -
for test situations like if-clauses.
For info, see http://zsh.dotsrc.org/Guide/zshguide02.html#l8 , last
paragraph.
Furthermore several cases of 'if [[..]]; then` where changed to the
otherwise used form 'if [[..]] ; then`.
Oneliners used:
% sed -i 's,\]\;\( then\),\] ;\1,' etc/{skel,zsh}/.#z*
% sed -i 's,[^\["]\(\[ \+[-!"$]\+\), [\1,g;s,\( ]\)\([ ;]\+\),\1]\2,g' etc/{skel,zsh}/.#z*

I checked the result several times. I really hope I did not miss any
false positive.