Unidentified subject!

[Quinn Dunkan <quinn@xxxxxxxxxxxxxxxxxxxxx>]

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