From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27410 invoked from network); 8 Oct 1997 23:20:50 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 8 Oct 1997 23:20:50 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id TAA15238; Wed, 8 Oct 1997 19:13:55 -0400 (EDT) Resent-Date: Wed, 8 Oct 1997 19:13:05 -0400 (EDT) Recieved: from tammananny.tiger (quinn@tammananny.tiger [127.0.0.1]) by tammananny.tiger (8.8.7/petrouchka) with ESMTP id QAA03342 for ; Wed, 8 Oct 1997 16:13:00 -0700 Message-Id: <199710082313.QAA03342@tammananny.tiger> To: zsh-users@math.gatech.edu Subject: Re: stuff Date: Wed, 08 Oct 1997 16:12:59 -0700 From: Quinn Dunkan Resent-Message-ID: <"LiC3e2.0.ui3.0E1Fq"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1061 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > > 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.