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 ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers

Reply via email to