Re: Moving completion functions

Re: Moving completion functions

[Oliver Kiddle]

First, I've got some comments relating to specific functions:

> Functions/Misc/acx		Functions/Examples	# Misc?
> Functions/Misc/cx		Functions/Examples	# Misc?

I'd delete these because they would be better written as aliases. They
could always be added to the example startup files.

> Functions/Misc/multicomp	Functions/Compctl

Is this one still relevant now that we have matching control.

> Functions/Misc/promptnl		Functions/Misc

This is new right? Was this something to do with evading the promptcr
problem?

> Functions/Misc/run-help		Functions/Misc	# Add #autoload line?

On the basis that functions starting #autoload are autoloaded by
compinit, and that #autoload was intended for functions which are part
of the completion system, should we be using #autoload in
non-completion system related functions. I'm not sure that I'd want
this autoloaded anyway because I don't use it.

> Functions/Misc/zless		Functions/Misc

I'd delete this one too because of the LESSPIPE feature in recent
versions of less. It could always be found a good home on the web
pages. If it stays, I'd put it in Examples.

> Functions/Misc/zls		Functions/Misc

This I'd definitely put in Examples. I can't believe anyone would use
it instead of their binary ls but it is a nice example for the stat
module.

Bart wrote:
> I've
> left in Functions/Misc anything that it seemed likely one might want to
> have in one's "standard" fpath, relocated stuff related to old compctl
> completions into Functions/Compctl, and stashed everything else in
> Functions/Examples.  A few of those latter might possibly want to be
> in Misc instead; I've marked those.

I agree with the Compctl division although it might be better to put
them in the compctl-examples file to get them out of the way.

For the rest it isn't very easy. The only ones which I can't see anyone
possibly wanting in their $fpath are zls and randline. pushd is
basically there for backward compatibility which would make a good
category if there were more. I would class acx, cx, harden, proto, yp,
yu, checkmail, mere, zed and zmv as useful functions which many people
might want to use. Most of the rest (zkbd, is-at-least, nslookup,
zstyle+, run-help, colors and zrecompile) are the ones which are almost
an integral part of zsh in that other things rely on them and they are
mentioned in the documentation.

This might suggest some sort of Example/Contrib/Zsh division although
that isn't want I originally meant to suggest. Maybe we could not
install the examples, have a configure option to install the user
contributions and always install the other things.

The other thing which might be worth doing is looking through any other
functions any of us have. From these we may find some suitable for the
distribution and others which can go under the user contributions on
the web pages.

I've attached two of mine: hgrep is like grep but highlights
matches. showargs lists arguments one per line which can be handy when
trying to work out what is going on with some quoting. Do you think
either of these may be suitable?

I also have these:
  freload() { while (( $# )); do; unfunction $1; autoload -U $1; shift; done }
  dr() { ls -lFbd ${@:-*}(/) }
  lx() { ls -lFbd ${@:-*}(x^/) }

The example startup files are another thing we should look at before
4.0. I'd be in favour of modifying them to use new-style completion and
having some typical example zstyles and generally to be a bit more
up-to-date. If there is agreement on this, I'll come up with a
suggested patch for them.

Finally, there was a mention at some point about changing the letters
of some compadd options as we were originally constrained by
consistency with compgen which had many of the old compctl options. Was
this ever done or looked in to? I suppose we still have compctl but
some could be better like -J and -V.

Oliver

Re: Moving completion functions

[Oliver Kiddle]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

I wrote:
> The other thing which might be worth doing is looking through any other
> functions any of us have. From these we may find some suitable for the

> I've attached two of mine: hgrep is like grep but highlights

Of course, it would help if I actually remembered to attach them.
They should be on this e-mail.

Oliver

[-- Attachment #2: hgrep --]
[-- Type: text/plain, Size: 361 bytes --]

# hgrep - highlight grep

if (( ! $# )); then
  echo "Usage: $0:t [-e pattern...] [file...]" >&2
  return 1
fi

local -a regex
local htext=`echotc so` ntext=`echotc se`

while [[ "$1" = -e ]]; do
  regex=( $regex "$2" )
  shift 2
done

if (( ! $#regex )); then
  regex=( "$1" )
  shift
fi

regex=( "-e
s/${^regex[@]}/$htext&$ntext/g" )
sed ${(Ff)regex[@]} "$@"

[-- Attachment #3: showargs --]
[-- Type: text/plain, Size: 103 bytes --]

local arg s

(( $# == 1 )) || s=s
echo received $# argument$s

for arg; do
  echo -E - ">>$arg<<"
done

Re: Moving completion functions

[Bart Schaefer]

On Mar 22,  9:46pm, Oliver Kiddle wrote:
> Subject: Re: Moving completion functions
> 
> > Functions/Misc/acx		Functions/Examples	# Misc?
> > Functions/Misc/cx		Functions/Examples	# Misc?
> 
> I'd delete these because they would be better written as aliases.

I agree, which (jumping ahead) is why I do NOT agree with:

> I would class acx, cx, harden, proto, yp, yu, checkmail, mere, zed
> and zmv as useful functions which many people might want to use.

I would include harden, checkmail, mere, and definitely zed as "useful
functions which many people might want to use," but proto is marginal
(how many people code in C with exactly Paul Falstad's style?) and to
autoload all those those trivial one-liners is IMO a waste.

> > Functions/Misc/multicomp	Functions/Compctl
> 
> Is this one still relevant now that we have matching control.

It's too big to reasonably put in compctl-examples and remains relevant
to anyone not using the new completion system.  (multicomp is like the
_path_files function; no real overlap with matching control AFAICT.)

> > Functions/Misc/promptnl		Functions/Misc
> 
> This is new right? Was this something to do with evading the promptcr
> problem?

Yes, you call promptnl from precmd.  I suppose it (or contrib.yo) should
say that, somewhere.

> > Functions/Misc/run-help		Functions/Misc	# Add #autoload line?
> 
> On the basis that functions starting #autoload are autoloaded by
> compinit, and that #autoload was intended for functions which are part
> of the completion system, should we be using #autoload in
> non-completion system related functions.

That's why there's a `?' at the end of my comment.  So, leave run-help
as it is.

> > Functions/Misc/zless		Functions/Misc
> 
> I'd delete this one too because of the LESSPIPE feature in recent
> versions of less. It could always be found a good home on the web
> pages. If it stays, I'd put it in Examples.

I have no objection to moving this to Example.

> > Functions/Misc/zls		Functions/Misc
> 
> This I'd definitely put in Examples. I can't believe anyone would use
> it instead of their binary ls but it is a nice example for the stat
> module.

This is also fine with me.

> I agree with the Compctl division although it might be better to put
> them in the compctl-examples file to get them out of the way.

I'd actually rather split compctl-examples up into smaller files and put
them all in Functions/Compctl, but I suppose we're trying to discourage
use of compctl ...

> The example startup files are another thing we should look at before
> 4.0. I'd be in favour of modifying them to use new-style completion and
> having some typical example zstyles and generally to be a bit more
> up-to-date. If there is agreement on this, I'll come up with a
> suggested patch for them.

The main thing I want to do with the example startup files is to add a
batch of comments, possibly in all-caps, telling system administrators
NOT to drop these files into /etc/z*.  And maybe even put a "return 0"
at the top of each file just in case some nimrod copies them to /etc/
without looking at them.

Re: Moving completion functions

[Oliver Kiddle]

Bart wrote:

> Long, long ago it was decided that it was a bad idea to import FPATH.
> So long ago that it's not in the zsh-workers archive, unfortunately.
> Probably has something to do with the fact that its a huge security
> hole, i.e., you can cause some other user's shell to inherit a trojan
> via any function you can guess he might autoload.

That's a good point. I have a horrible feeling you mentioned that before
sometime. It made me wonder though: surely PATH is similar. I've always
tended to add to the path in my .zshrc so this makes me wonder if it
wise to set it fully and in .zshenv for similar security reasons.
 
> } As I said with the original suggestion, there could be a variable set
> } to point to the base of the installed functions.
> 
> A parameter set how?  By hardwiring it at compile time?  I suppose that
> the zsh/complete module could define one.

Yes, or in the same way as how $fpath is set. I've used things like
${fpath[(r)*Core]:-$fpath[(r)*/functions]} in a few places (such as my
zrecompile script) to get at this directory so it might be useful
anyway.

I did a bit of thinking last week and as for the whole suggestion about
setting $fpath, I think you've convinced me that the current situation
is probably just as good/bad as my suggestion. I think it would
definitely be worse if we ended up supporting both ways of doing it with
a configure option so I won't mention it again. So I suggest we leave it
as it is and I shut up.

> } Do we need to account for kshautoload though?

> The only way is to "zcompile -z" the whole thing and then put the .zwc
> file in fpath.  This has been mentioned before (it may even be in the
> docs somewhere).

I couldn't see it in the docs but these things aren't so easy to find.
If it gets asked much, we can always add it to the FAQ.

As for sourcing compinit, I suppose it might have a performance
implication. I just felt that sourcing is more natural for what it is
doing and is possibly an easier concept for new users to understand.
>From the perspective of my own use of zsh, I don't really care how
compinit does its stuff. I'm not too keen on us complicating compinit so
that sourcing it is an option but with autoload being the method
mentioned in the manual.

Bart Schaefer wrote:
> 
> I would include harden, checkmail, mere, and definitely zed as "useful
> functions which many people might want to use," but proto is marginal
> (how many people code in C with exactly Paul Falstad's style?) and to
> autoload all those those trivial one-liners is IMO a waste.

Sorry, I didn't really know what proto was but assumed it was something
more general and so more useful.

> It's too big to reasonably put in compctl-examples and remains relevant

fair enough. Again I've never used it and just glanced to see what it
did.

> > > Functions/Misc/run-help             Functions/Misc  # Add #autoload line?
> >
> That's why there's a `?' at the end of my comment.  So, leave run-help
> as it is.

Er? I saw the ? and meant my comment as an answer but probably got the
tone of it wrong.

In some ways, I wonder that #autoload as a wider feature might be
useful.

> I'd actually rather split compctl-examples up into smaller files and put
> them all in Functions/Compctl, but I suppose we're trying to discourage
> use of compctl ...

That's not a bad idea. They'd be out of the way in the Compctl directory
so I don't think it would be too much of an encouragement. More
functions in Compctl would better justify its existence. I've also been
convinced that compctl still serves a purpose.

> The main thing I want to do with the example startup files is to add a
> batch of comments, possibly in all-caps, telling system administrators
> NOT to drop these files into /etc/z*.  And maybe even put a "return 0"
> at the top of each file just in case some nimrod copies them to /etc/
> without looking at them.

I would definitely agree with that.

Oliver

Re: Moving completion functions

[Peter Stephenson]

Oliver Kiddle wrote:
> Bart wrote:
> > The main thing I want to do with the example startup files is to add a
> > batch of comments, possibly in all-caps, telling system administrators
> > NOT to drop these files into /etc/z*.  And maybe even put a "return 0"
> > at the top of each file just in case some nimrod copies them to /etc/
> > without looking at them.
> 
> I would definitely agree with that.

As far as I'm concerned a nimrod is (a) a hunter mentioned in Genesis (b)
one of the Enigma variations referring to Elgar's friend and publisher
A.J. Jaeger (c) a search and reconnaissance aircraft, but if someone wants
to do that that's fine by me.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

PATCH: nimrod proofing

[Bart Schaefer]

On Mar 25,  9:39pm, Peter Stephenson wrote:
} Subject: Re: Moving completion functions
}
} > > [...] maybe even put a "return 0"
} > > at the top of each file just in case some nimrod copies them to /etc/
} 
} As far as I'm concerned a nimrod is (a) a hunter mentioned in Genesis

``... the first who claimed to be a "mighty one in the earth."'' according
to Easton's 1897 Bible Dictionary (see http://www.dict.org/).

Hence a nimrod is someone who overestimates his own power or ability.  I
don't remember where I first heard that usage ...

} but if someone wants to do that that's fine by me.

Index: StartupFiles/zlogin
===================================================================
--- StartupFiles/zlogin	1998/06/01 17:08:46	1.1.1.1
+++ StartupFiles/zlogin	2001/03/25 23:21:34
@@ -8,6 +8,9 @@
 # msgs, from, etc).
 #
 
+# THIS FILE IS NOT INTENDED TO BE USED AS /etc/zlogin, NOR WITHOUT EDITING
+return 0+
 clear
 stty dec new cr0 -tabs
 ttyctl -f  # freeze the terminal modes... can't change without a ttyctl -u
Index: StartupFiles/zshenv
===================================================================
--- StartupFiles/zshenv	1998/06/01 17:08:46	1.1.1.1
+++ StartupFiles/zshenv	2001/03/25 23:22:11
@@ -9,6 +9,9 @@
 # output or assume the shell is attached to a tty.
 #
 
+# THIS FILE IS NOT INTENDED TO BE USED AS /etc/zshenv, NOR WITHOUT EDITING
+return 0	# Remove this line after editing this file as appropriate
+
 export X11HOME=/usr/X11
 
 path=($X11HOME/bin)
Index: StartupFiles/zshrc
===================================================================
--- StartupFiles/zshrc	1998/06/01 17:08:46	1.1.1.1
+++ StartupFiles/zshrc	2001/03/25 23:21:58
@@ -6,6 +6,9 @@
 # options, key bindings, etc.
 #
 
+# THIS FILE IS NOT INTENDED TO BE USED AS /etc/zshrc, NOR WITHOUT EDITING
+return 0	# Remove this line after editing this file as appropriate
+
 # Search path for the cd command
 cdpath=(.. ~ ~/src ~/zsh)
 


-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: nimrod proofing

[Bart Schaefer]

On Mar 25, 11:27pm, Bart Schaefer wrote:
} Subject: PATCH: nimrod proofing
}
} Hence a nimrod is someone who overestimates his own power or ability.

Speaking of which ...

} +# THIS FILE IS NOT INTENDED TO BE USED AS /etc/zlogin, NOR WITHOUT EDITING
} +return 0+

Bleah; I'm not having very good luck with patches today.  This one got
corrupted somehow; that hunk should have looked just like the others:

+return 0	# Remove this line after editing this file as appropriate
+

I'm not going to bother mailing another patch, I'll just commit it the
right way.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Moving completion functions

[Bart Schaefer]

(Gotta find some more zsh-workers in my timezone.  Half the time I feel
like I'm talking to myself.  "... and the award for the most consecutive
messages to zsh-workers, none intercepted, goes to ...")

On Mar 25,  4:26pm, Oliver Kiddle wrote:
} Subject: Re: Moving completion functions
}
} Bart wrote:
} > I'd actually rather split compctl-examples up into smaller files and put
} > them all in Functions/Compctl, but I suppose we're trying to discourage
} > use of compctl ...
} 
} That's not a bad idea. They'd be out of the way in the Compctl directory
} so I don't think it would be too much of an encouragement.

Unfortunately, thinking about it a bit more, most of compctl-examples is
not functions but compctl commands.  Unlike the new completion system,
there's no convenient way to autoload them, so putting them under the
Functions directory doesn't make as much sense.

Unless ...

I just had a wonderful, awful idea ... one could use `compctl -T' to call
a function, which runs an autoloaded function, which defines a compctl,
which is then called because the -T attempt didn't generate a match ...

Oh, dear.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net