Re: zsh

[Peter Stephenson <pws@xxxxxxx>]

Atousa Pahlevan wrote:
> Hi,
> I am trying to find out the architecture of zsh.But I only find subsytems
> which all of them talk to each other.I haven't find any pipe & filters or
> even the other pattern for it(only a graph).Please guid me to do this.

There's no detailed documentation about the overall structure.

Start looking at loop() in init.c.  This is the main command loop (it's
also used internally).  There's a lot of initialisation before that, but
you don't need that for a first pass.

There are basically two steps to each set of commands: parse it, then
execute it.  Parsing (in parse.c) reads tokens from the lexer (in lex.c)
which in turn gets bytes from the history mechanism (in hist.c: in
non-interactive shells this is a fairly shallow layer over input.c), which
uses the input mechanism (in input.c), which either reads lines directly
from its input or, in an interactive shell, reads a line from the line
editor in the Zle directory via a call to zleread().

You'll see in loop() there are calls to hbegin and hend, which
initialise the history mechanism, and to lexinit, which initialises the
lexical analyser.  The input mechanism just passes its request on and
zleread will perform its own initialisation when it needs it.

Then the command line is read by a call to parse_event().  You can
(maybe!) trace how that works that through parse.c.  This returns a
pointer to a "struct eprog", which is a highly compacted version of the
parsed code.

This is then passed via execode() down to the code in exec.c which
executes it.  The code there roughly corresponds to the documented
grammar in the zshmisc manual page (as, indeed, does parse.c).  The core
of this is execcmd, which executes each individual command with its
arguments.  The pipeline stuff at the level above is particularly
complicated in order to get job control to work properly.  exec.c makes
a lot of use of the functions in jobs.c which records jobs and processes
mostly for interactive job control; the file signal signals.c is also
related and contains the handler function zhandler used, among other
things, for recording the fact that a child process has executed.

Every stage of the process is cluttered by lots of little details you
don't need to know in the first instance; unfortunately it's not clearly
spelled out what's essential and what isn't.

-- 
Peter Stephenson <pws@xxxxxxx>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************