On Fri, Jul 27, 2012 at 5:26 PM, Glenn Fowler <g...@research.att.com> wrote:
>
> 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
Erm... I think you misunderstood me. There would be two cmdtst incarnations:
1. "cmdtst" - the current one, only links against libast
2. "shellcmdtst" - the new one, which links against libshell and libast
In case of a static build both would be dumped into ksh93.
> 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
Uhm... what exactly do you mean ?
----
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
