From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17573 invoked from network); 11 Oct 1997 07:19:10 -0000 Received: from ns2.primenet.com.au (7795@203.24.36.3) by ns1.primenet.com.au with SMTP; 11 Oct 1997 07:19:10 -0000 Received: (qmail 1118 invoked from network); 11 Oct 1997 07:19:03 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns2.primenet.com.au with SMTP; 11 Oct 1997 07:19:03 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id DAA06976; Sat, 11 Oct 1997 03:05:29 -0400 (EDT) Resent-Date: Sat, 11 Oct 1997 03:05:11 -0400 (EDT) Recieved: from tammananny.tiger (quinn@tammananny.tiger [127.0.0.1]) by tammananny.tiger (8.8.7/petrouchka) with ESMTP id AAA01332 for ; Sat, 11 Oct 1997 00:05:16 -0700 Message-Id: <199710110705.AAA01332@tammananny.tiger> To: zsh-users@math.gatech.edu Date: Sat, 11 Oct 1997 00:05:15 -0700 From: Quinn Dunkan Resent-Message-ID: <"s2tZG.0.Ui1.cKoFq"@math> Resent-From: zsh-users@math.gatech.edu Subject: Unidentified subject! X-Mailing-List: archive/latest/1079 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu >>> A $LASTPID or something parameter, which is the pid of the last command run. >>> Yes, I know about $!, but that only works if the process is &ed and not at all >>> if it forks like a daemon (or maybe daemons pitchfork() ?). > > Don't let go of that tiger's tail. He'll take you on a nice ride... Not really, he turned around and bit me pretty early on, right next to my ctty and session-id tiger-bites. >>> 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. > > Show us a shell in which you can, and we'll duplicate it. ;> If that had to be done for every zsh feature, I'd be using the other shell. There may be a good reason no one else has done it, but I don't know it, and no one has told it to me. zsh should never hesitate to innovate (and with modules, experimental features will be easy(er) to implement without annoying all the conventionalists. > >> 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. > > Be sensible. EDITOR, HISTFILE, HISTSIZE, LESS, PAGER, VISUAL, and other > such environment variables shouldn't be in zshenv - they can only be > used in interactive shells. Of course, setting every environment > variable I set takes less than a second; it doesn't hurt *that* much > unless you have a *lot* of shell scripts that read /etc/zshenv. I didn't mention HISTFILE, HISTSIZE, etc., because I know those are usually useful only for interactive sessions. LESS, however, can certainly affect things, I have a number of scripts which do the ${=PAGER:-less} thing. > Question: would it be possible to avoid this whole problem by re-writing > /sbin/init as a zsh script? That way, it can export all of the variables, > and so you don't need to worry about cron-executed programs having a > different environment. That's an interesting idea. Not for enviroment changes---I agree with zefram that scripts should be independent of whatever zsh enviroment they happen to be in---but because it would be sort of cool. Let's see, you need to muck with utmp/wtmp, catch signals, respawn things... nothing I can think of that a shell script couldn't do. Whether that's a good idea is another matter... besides, my init exports a couple of env vars (INIT_VERSION, CONSOLE, RUNLEVEL, and PREVLEVEL), and it's all destroyed by /bin/login anyway. With the perl thing, I think zsh modules should add new ways to interact with zsh, not reproduce functionality that already exists in external programs. I'm not sure why people are reproducing ls, cp, etc. as builtins, though. The only advantage that I can think of a perl builtin would have over perl -e '' at the command line would be keeping it's variables around. Actually, it shouldn't be to hard to turn perl into a shell, it has an autoloading feature you can use to tell it to try system() on functions it can't find. Just make the autoload function smart enough to parse pipes, redirections, ampersands, and all that shellish stuff, and maybe make newline acceptable for ;. You'd have to change some more things, like having @path instead of $path, and integrating %ENV and the normal %MAIN namespace. We've got our settor functions too :) I'm not _extra_ crazy about programming in perl, but I'm less crazy about programming in shell, and programming in perl and shell at the same time would make me totally crazy. Meanwhile, while people _are_ writing builtins for cp, ls, etc, there's part of our solution to the chase_links problem. Also, I wonder what people think of ``fake filesystems'', like .tar.gz and ftp ``directories''. Of course, this sort of thing is much better handled in the kernel (well, actually much better handled by a user-mode filesystem server, but unix doesn't do that), but as long as we're stuck with what we've got, it would be sort of cool. Of course, you'd need some extra zsh stuff, like directory cacheing, but it seems fairly feasible, at least to me. Desirable? I dunno... BTW, what is the use of the > and < redirections? It seems they could be replaced with `re file | cmd' and `cmd | wr file' (read and write are already taken). It would be more to type, but the current distinction shells make between pipes and redirections has always been strange to me. Does the shell really need a way to read and write directly to files? It seems it would be easier to replace this <, >,>&,#>&#, >>, etc. etc. syntax with | and #| (#| piping fd # to a coprocess). Then all that complex and messy redirection stuff can be replaced by a simple external program (or builtin), so instead of `cmd >>foo' you do `cmd | wr -a foo'. I'm just trying to stir things up here :) Well, this doesn't really have to do with zsh, but has anyone noticed where pty (the program suite) went? It doesn't seem to be as widespread as its coolness warrants. I couldn't find a linux port so I hacked my own. I ask because the author had a lot of interesting things to say about job control and ttys, the sorts of things shell-developers would also know about.