On Tue, Jul 24, 2012 at 10:27 PM, Lionel Cons
<lionelcons1...@googlemail.com> wrote:
> On 24 July 2012 21:11, David Korn <d...@research.att.com> wrote:
>> cc: ast-developers@research.att.com
>> Subject: Re: Preventing linker from removing ksh93 builtins which are not
>> enabled by default ... / was: Re: [ast-developers] Prototype poll(1)
>> builtin...
>> --------
>>
>>> On Fri, Jul 20, 2012 at 4:31 PM, Irek Szczesniak <iszczesn...@gmail.com>
>>> wrote:
>>> [snip]
>>> > 5. Linker issues: shtab_builtins in src/cmd/ksh93/data/builtins.c is a
>>> > NULL-terminated list. You can put builtins like poll(1) which should
>>> > not be enabled by default *after* the NULL slot.That should "anchor"
>>> > them. This would be a general solution to the ongoing s**t that a lot
>>> > of builtins are not available in the AT&T default binaries because the
>>> > *y************-linker removes them.
>>>
>>> I tried that... this prevents the |b_poll()| symbol from being removed
>>> at the final link step but ksh93 then won't be able to find it. It
>>> seems the problem is that ksh93 somehow doesn't look inside itself for
>>> builtins specified via $ builtin fooname #, e.g. without -f libname
>>> (and if I specify $ builtin -f $0 poll # ksh93 comes back and
>>> complains about the missing |plugin_version()|).
>>>
>>> Or short: Your "anchoring" idea works... but we need more work to make
>>> it practially useable...
>>
>> We could add another table of potential builtins,
>>
>> const struct shtable3 shtab_xbuiltins[] =
>> {
>> };
>>
>> and then modify builtin to lookup the built-in in this
>> table after looking in loaded libraries and checking
>> that it is not already a built-in.
>>
>> Thus, shtab_xbuiltins will behave like a built-in library
>> except that each entry can have its own pathname associated with it.
>
> Is there anything which speaks against the idea of enabling the poll
> builtin by default without a path binding? The POSIX standard
> explicitly allows such builtins and shells like ksh88/ksh93/bash use
> them unconditionally.
Mhhh... I don't see any technical problems with that (defining a
function called "poll" will in any case have precedent over a "poll"
builtin utility... leaving external commands with the same name as
only potential source of incompatibilities. I've put out a larger call
of "... please find me a executable called 'poll'..." a week ago and
the feedback was "none here" (with more sarcastic comments like
"...please send back engineer who was so dumb to call a
script/executable with the same of a C library function...")).
I'm still thinking about this...
... but before doing that I'd like to do some changes to poll(1) ... including:
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
----
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
