Re: stuff

Re: stuff

[Quinn Dunkan]

> > 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.

Re: stuff

[Andrew Main]

Quinn Dunkan wrote:
>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?

Right.  Normal setup should go in ~/.z*.  /etc/z* should be basically
transparent, and used only for site-specific unavoidable hacks.

>                                              Currently I have in /etc/zshenv
>zmodload dependencies, setopts, and a bunch of vars (everything non-interactive
>shells could use).

Those should go in ~/.zshenv, except possibly the zmodload bits.
By setting variables, and especially options, in /etc/zshenv, you are
changing the semantics of zsh.

The system I use here, at work, illustrates this point quite well.
/etc/zshrc contains some bindkeys for escape sequences sent by local
terminals, which is quite valid.  /etc/profile, however, is basically
taken from one of the Linux distributions, and sets up all sorts of
environment variables -- enabling colour ls, and providing a rather poor
LESSOPEN -- which make life awkward for me, so I have to override all
of these variables in my .profile.

>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.

Don't write scripts to run in your customised enviroment.  Write them
for plain zsh -f.

>FITNR = ?

Fixed In The Next Release.  3.1.3 in this case.

>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*).

That sort of thing can go in the prompt.  If your terminal has an actual
status line, it can use that.

>haven't played around with the module interface yet---can you override internal
>zsh functions, or just add new builtins?

Somewhere between.  You can override anything that the base code
explicitly allows to be overridden.

>Speaking of es, I wonder if zsh could steal some of es's features, such as
>settor functions.

I've been considering doing that for a while.  I can see a number of uses
for it, and we could actually remove the hardcoded special handling of
most special variables.  (PATH and path, for example, could each have
a settor function that sets the other.)

>               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)?

Potentially possible.  I'd like to play with this idea.

>                                                                Hell, you could
>link a syntax module in with libperl and come up with that perl shell
>everyone's always asking about.

That's actually going one step beyond another idea I'd had -- to link
libperl into a module that provides the perl command as a builtin.

-zefram

Re: stuff

[Bruce Stephens]

zefram@tao.co.uk said:
> That's actually going one step beyond another idea I'd had -- to link 
> libperl into a module that provides the perl command as a builtin. 

Adding dynamically loadable perl (and other) syntax is a cool idea, though.  
We could write perl functions, and have them just work without an extra 
process.

Re: stuff

[Tim Writer]

Andrew Main <zefram@tao.co.uk> writes:

> Quinn Dunkan wrote:
> >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?
> 
> Right.  Normal setup should go in ~/.z*.  /etc/z* should be basically
> transparent, and used only for site-specific unavoidable hacks.
> 
> >                                              Currently I have in /etc/zshenv
> >zmodload dependencies, setopts, and a bunch of vars (everything non-interactive
> >shells could use).
> 
> Those should go in ~/.zshenv, except possibly the zmodload bits.
> By setting variables, and especially options, in /etc/zshenv, you are
> changing the semantics of zsh.
> 
> The system I use here, at work, illustrates this point quite well.
> /etc/zshrc contains some bindkeys for escape sequences sent by local
> terminals, which is quite valid.  /etc/profile, however, is basically
> taken from one of the Linux distributions, and sets up all sorts of
> environment variables -- enabling colour ls, and providing a rather poor
> LESSOPEN -- which make life awkward for me, so I have to override all
> of these variables in my .profile.

But isn't that just the point.  Knowledgeable users like yourself can
override global settings and get the environment they like.  But less
knowledgeable users don't have the skills, so system administrators, who may
be responsible for managing a large number of machines and assisting a large
number of users, really have no choice but to provide a reasonably nice (site
specific) environment (i.e. not the default) via /etc/z*.  Keeping novices
and experts happy is hard.  Ultimately, most sys. admins. are going to do
whatever makes their job easier.

> >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.
> 
> Don't write scripts to run in your customised enviroment.  Write them
> for plain zsh -f.

Good advice, but not always easy to follow.  Sometimes scripts have to be
aware of the customized environment because there purpose is to report on it
or manipulate it.  Again, I'm thinking of a sys. admin. writing support
scripts for less knowledgeable users.

> >Speaking of es, I wonder if zsh could steal some of es's features, such as
> >settor functions.
> 
> I've been considering doing that for a while.  I can see a number of uses
> for it, and we could actually remove the hardcoded special handling of
> most special variables.  (PATH and path, for example, could each have
> a settor function that sets the other.)

Doesn't ksh '93 have similar functionality?  I think they're called
discipline variables.  Perhaps zsh should go that route as ksh emulation
seems to be a clear goal.

Speaking of ksh '93, what about hierarchical variables?

-- 
Tim Writer                                              Tim.Writer@ftlsol.com
FTL Solutions Inc.
Toronto, Ontario, CANADA

Re: stuff

[Andrew Main]

Tim Writer wrote:
>                                              system administrators, who may
>be responsible for managing a large number of machines and assisting a large
>number of users, really have no choice but to provide a reasonably nice (site
>specific) environment (i.e. not the default) via /etc/z*.

No, that's what /etc/skel is for.

-zefram

Re: stuff

[Tim Writer]

Andrew Main <zefram@tao.co.uk> writes:

> Tim Writer wrote:
> >                                              system administrators, who may
> >be responsible for managing a large number of machines and assisting a large
> >number of users, really have no choice but to provide a reasonably nice (site
> >specific) environment (i.e. not the default) via /etc/z*.
> 
> No, that's what /etc/skel is for.
> 

I disagree.  The purpose of /etc/skel is to provide an INITIAL environment.
It doesn't solve the (much more difficult) problem of MAITAINING a
consistent, friendly environment for those users that don't have the skills
to do it themselves.

Re: stuff

[Andrew Main]

Tim Writer wrote:
>> No, that's what /etc/skel is for.
>
>I disagree.  The purpose of /etc/skel is to provide an INITIAL environment.
>It doesn't solve the (much more difficult) problem of MAITAINING a
>consistent, friendly environment for those users that don't have the skills
>to do it themselves.

I see what you mean.  You need to have one single set of shell setup
files, that will be used by any user that makes no attempt to change eir
setup.  However, I disagree that these need to be called /etc/zshenv etc..
It would be much better to have an /etc/skel setup with files that just
source your master files, which you can keep anywhere you want (say,
/usr/local/lib/skel).

-zefram

Re: stuff

[Tim Writer]

Andrew Main <zefram@tao.co.uk> writes:

> Tim Writer wrote:
> >> No, that's what /etc/skel is for.
> >
> >I disagree.  The purpose of /etc/skel is to provide an INITIAL environment.
> >It doesn't solve the (much more difficult) problem of MAITAINING a
> >consistent, friendly environment for those users that don't have the skills
> >to do it themselves.
> 
> I see what you mean.  You need to have one single set of shell setup
> files, that will be used by any user that makes no attempt to change eir
> setup.  However, I disagree that these need to be called /etc/zshenv etc..
> It would be much better to have an /etc/skel setup with files that just
> source your master files, which you can keep anywhere you want (say,
> /usr/local/lib/skel).

Actually, that's what I do in practice.  But I set up some basic machinery in
/etc/zshenv.