On Fri, 27 Jul 2012 16:43:37 +0200 Roland Mainz wrote:
> On Fri, Jul 27, 2012 at 3:23 PM, Glenn Fowler <g...@research.att.com> wrote:
> > On Fri, 27 Jul 2012 15:07:47 +0200 Lionel Cons wrote:
> >> On 27 July 2012 07:13, Roland Mainz <roland.ma...@nrubsig.org> wrote:
> >> > Attached (as "astksh_builtin_poll20120725_001.diff.txt") is the
> >> > _prototype_ patch for a poll(1) builtin and a demo application
> >> > (attached as "shircbot.sh.txt") which shows it's usage.
> >> >
> >> > Basic usage example:
> >> > -- snip --
> >> > $ ksh -c 'builtin poll ; function l { compound -a pl=( fd=0
> >> > events="POLLIN" ) ; poll pl ; print -v pl ; } ; l '
> >> > <enter a character>
> >> > (
> >> > (
> >> > events=POLLIN
> >> > fd=0
> >> > revents=POLLIN
> >> > )
> >> > )
> >> > -- snip --
> >> >
> >> > See output of $ poll --man # for usage and
> >> > https://mailman.research.att.com/pipermail/ast-developers/2012q3/001585.html
> >> > for further comments...
> >> >
> >> > Changes since the last version:
> >> > - Associative arrays now work. I've added a basic workaround for the
> >> > issue that walking an associative compound variable array using the
> >> > |nv*()|-API and then adding compound variable members to an existing
> >> > compound variable array element adds a new [0] element... which
> >> > screwed-up builtin internals. The "workaround" is to remember the
> >> > array subscripts and use these to write into the compound variable
> >> > array instead of doing this while walking the array using the
> >> > |nv*()|-API.
> >> > - "shircbot.sh" has been updated to use an associative array for poll(1)
> >> > data
> >> > - tty raw/cooked handling now uses the correct fd numbers. There is
> >> > still the issues that this doesn't really work with multiple different
> >> > ttys because the underlying |tty_raw()|/|tty_cooked()| API is not
> >> > designed for that.
> >> > - Some error handling has been fixed. The code is still so ugly that
> >> > little kitten will get blind and implode.
> >> >
> >> > ToDo:
> >> > - Fix usage of |sfpoll()| ... IMO it should only be called _once_ per
> >> > poll(1) call (poll(2) still needs to be called to listen for
> >> > POLLHUP&co.)
> >> >
> >> > - POSIX-like shell mode (e.g. add API which makes it possible that
> >> > poll(1) can be implemented by dash(1) or bash(1) or other shells which
> >> > do not have compound variables):
> >> > 1. If the input variable is a plain string array (not compound
> >> > variable array) it should read those strings and append/replace
> >> > "revents='...'" to those strings (this is mainly intended for
> >> > simplification and to allow authors to write a bash4/zsh/dash version
> >> > of poll(1) without having to implement compound variable support
> >> > first... ;-/ )
> >> > 2. If the input variable is a compound variable array or type variable
> >> > array "events" and "revents" should be compound variables themselves
> >> >
> >> > - Fix timeout when poll(2) needs to be restarted after EINTR/EAGAIN
> >> >
> >> > - EXAMPLES section in manpage... but I hit an issue with ']' ...
> >> > mhhh... AFAIK we had a similar request in the list this month: How do
> >> > I quote ']' that |_ast_getopts()| interprets it as plain text ?
> >
> >> When do you think will poll(1) be ready for integration into ast-ksh?
> >
> > it looks like today we will get the final ksh93u+ beta out
> > poll(1) integration will be with some ksh93v- alpha
> Erm... please let me change the API first and add a test module...
> > in the meantime, if poll(1) were added to cmdtst, it could be
> > tested with current ksh93u+ without recompilation
> AFAIK this doesn't work because poll(1) depends on the |nv*()|-API and
> libshell internal APIs (like |tty_raw()| and |tty_cooked()|) ... but
> IMO you are right that something like that would be nice for _testing_
> purposes...
> ... what about adding a new libshellcmdtst which works like cmdtst but
> links against libshell ?
that would require ksh and cmdtst both linked against shared/dll -lshell
the only system that does that by default is uwin because windows is already
dll giddy
unix shared lib startup times and bootstrap / sysadmin requirements make
ksh +lshell (libshell.a) the default
well, that may be a bit restrictive
if ksh were linked with +lshell and -lcmdtst linked with -lshell
and if the parts of -lshell used by -lcmdtst did not involved globals
(i.e., all ops relied on Shell_t*)
and if -lshell and +lshell were the same implementation modulo dynamic vs static
then it would/should work
I believe part of the ksh93v work will be to get the apis to that state
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
