Re: stuff

[Quinn Dunkan <quinn@xxxxxxxxxxxxxxxxxxxxx>]

> > As much as I try, I can't figure out a good way to have zsh execute some
> > command at startup and stay in interactive mode.

	(Peter Stephenson)
> I don't think there is one within the shell.  You could make your
> own arrangement:  add a line to .zshrc to . a particular file if it
> exists, then delete it, and write a trivial script which creates the
> file, then exec's zsh.  There are no doubt equally unpleasant ways.

    Actually my current arrangement is:

if [[ ! -z "$RUNFIRST" ]]; then
    setopt norcs
    ${=RUNFIRST}
    return
fi

Then I can do 

RUNFIRST=~/.zshrc.xterm1 xterm -e zsh -f&

but this is sort of ugly.

	(zefram)
> Funnily enough, `interactive' implies interaction with the user.  If you
> want interaction in a shell script, use vared.

No, I don't really want interaction in a shell script, I just want a startup
command, sort of like a ``command line .zshrc'', that is executed before any
rcs.  Not only would this eliminate monstrosities like my RUNFIRST line, but
would also give better control over the startup process (zsh -f could be
replaced with zsh -r 'setopt norcs', blah blah).

> > if zsh gets a parsing error in an rc file, you get something like:
> > zsh: unmatched ' [97]
> > with no indication of what rc file bombed.  Would it be possible to include
> > the name of the file it came from (how it works for .), so you get
> > ~me/.zshrc: unmatched ' [97] ?
> 
> This is now fixed, but I couldn't tell you since when now is.

Oops, you're right, zsh-3.1.2 does it right.

> What isn't yet fixed is that with shared libraries, zle doesn't get linked
> in until late in the initialisation, and zerr tries to call trashzle(),
> with the result that `zsh unknown-file' dumps core.  I haven't found
> a cleaner fix than adding if (trashzleptr) to zerr().

    How odd, I haven't had any problem here.  I just have

zmodload -d zle comp1
zmodload -a zle bindkey zle vared

in /etc/zshenv, and everything works fine...

> >                  I wound up changing the configure script (dlopen is in -ldl
> >on my linux system), and altering zshxmods.h and bltinmods.list to get a
> >modular binary.
> 
> What did configure --enable-dynamic get wrong?  It does look for libdl.

    Well, I did tar xvzf zsh-3.1.2.tar.gz zsh-3.1.2/configure and reconfigured
with --enable-dynamic, and behold, everything works right.  I don't know how
I managed to mess it up, but I recall deleting config.cache and reconfiguring
with --enable-dynamic a number of times and it not working before.  Then I saw

linux*|irix*) DLLDFLAGS="${DLLDFLAGS=-shared}" ;;

said aha, and stuck -ldl after that, and everything worked.  *shrug*

> Can't be done.  There's no way to distinguish a pathname from any other
> argument.  In any case, a program might generate .. segments itself.

    Of course you're right, oh well.  Time to go hack the kernel :)

> If the program daemonises, a $LASTPID wouldn't help.  If you want a
> PID, you can just background the command -- use wait is you then want
> synchronicity.

    Phoo, right again.  I guess it's back to rummaging through /proc (and
it the task is swapped out, you can't get its cmdline!)

> Ah, but with the new widget interface it's a trivial matter of programming
> for each user to write the interface to their own brain scanner.

Microsoft seems to have come up with an effective approach: generate random
syntactically correct commands, then convince the users that it's all nasty
complicated technical stuff and they'd best just accept whatever is
automatically generated as the best thing.  This avoids the overhead of
actually predicting things.  I'll bet you could even have it open a socket to
some central computer and read commands from there (oh sure, a few people might
whine about the security implications, but we could just ignore them).

>>To add some more confusion to the rc file thread, I don't quite understand the
>>reasons for zprofile/zlogin.
> 
> .zprofile is run first thing, in the manner of .profile.  .zlogin is
> a csh-like feature -- it is sourced after the normal shell startup,
> and so has the user's full normal environment available.
> 
>>         Also, is it better to stick vars in zlogin and export them so future
> >shells inherit them, or put things like PATH, MANPATH, HOSTNAME, etc. in
> >zshenv?
> 
> Put them in zshenv, and export if appropriate.
> 
> >                                   Is it better to let progs inherit their
> >enviroments rather than rescan a large /etc/zshenv every time?
> 
> You shouldn't have anything in /etc/zshenv.  Most zsh scripts should
> also start "#!.../zsh -f" to avoid scanning any initialisation files.

Uh, maybe you're talking about different zshenvs?  That bit about ``put them
in zshenv'', and ``You shouldn't have anything in /etc/zshenv'' confused me a
bit.  Likely the first zshenv was ~/.zshenv?  Currently I have in /etc/zshenv
zmodload dependencies, setopts, and a bunch of vars (everything non-interactive
shells could use).
If this wasn't a single user system I'd stick setopts in .zshenv, but I don't
want cron jobs, sendmail prog agents, etc. running zsh scripts in unexpected
ways, so they're global.

> Can't be done.  Yet.  I want to make it possible eventually, so that we
> can have a ticking clock in the prompt.
> 
> >                                                        I tested this with
> >zle clear-screen instead of the (nonexistent) redraw-line,
> 
> You want redisplay.
> 
> >                                                           and the prompt
> >came back mangled (spaces and high chars),
> 
> FITNR (I think), but it won't change the prompt.
> 
> Actually, that's rather annoying.  I noticed that zsh had a problem with
> this when I first used it, back in 2.6-beta4 or so.  I fixed it in the
> 2.6 series, but due to this causing some other problem it was removed
> for 3.0.  The new fix in 3.1 does things properly, but that's too late
> for the thousands of people using 3.0.

Actually, I'm using 3.1.2 for this.  I tried

function my-vi-cmd-mode { PS1='%B%#%b '; zle redisplay; zle vi-cmd-mode }

and bound it in, but escape still changes my prompt to weird chars and many
spaces the first time.  The weird prompt is always a little bit different.

FITNR = ?

I thought I'd throw this idea out and see what people think...  zsh could have
a status line on the bottom of the screen, which would give info such as time,
loadavg, mail, anything the user wanted, really ("click here to start"
*shudder*).  I tried an external program supposed to do this, but it freaked
out with full-screen apps like less and vi (even after hacking /etc/termcap and
some stty settings, less seemed to figure out how many lines I _really_ had and
reset to that).  If the status line was part of the shell maybe it could be
better at keeping $LINES more consistent (stty lines 49; ttyctl -f) ?  I
haven't played around with the module interface yet---can you override internal
zsh functions, or just add new builtins?

Undoubtably this has been mentioned, but the only way I can figure out to

I've noticed the behaviour of '.' has changed:
zsh 3.0.0 % . /dev/tty
quits after one command, where
zsh 3.1.2 % . /dev/tty
does the expected thing, like . -i in rc and es.

Speaking of es, I wonder if zsh could steal some of es's features, such as
settor functions.  Obviously, they would be 'real' functions in zsh instead
of lambda variables (can you compose anonymous functions on the fly in zsh? or
``higher-order functions'' and partial applications (function returns function
that further evaluates command line))?  Or maybe the answer is ZSHINSCSH (zsh
is not scsh).  For those who prefer rc / es syntax over 'normal' shells, I
don't suppose it would be possible for a module to override zsh's syntax parser
(or better yet, just make the the default parser be sh-ksh-csh.so, then when
you do ``emulate ksh'' or something, it dumps sh-ksh-csh.so and loads ksh.so)?
So we could reduce the shell to a bunch of utility functions, and modules just
parse command lines to call the utility functions, or other modules, which
would make zsh configurable beyond recognition (that's good!).  Hell, you could
link a syntax module in with libperl and come up with that perl shell
everyone's always asking about.  In the future, you start up your voice
recognition daemon, insert the english.so module (opens a socket to the
daemon), and say "computer, fire phaser bank one".

With proper application of modules, zsh could contend with emacs for the
grossly-overfeatured crown, but keep fairly small and fast if that's what you
want.