TODO: print -S <varname> option
The "print" utility should get a -S option to specify a variable
where the output should be stored as string value.
The idea is to replace common usage like
s=$(print "hello")
which currently causes a row of |open()|,|write()|,|seek()|,|read()|,|close()|
needed for the command substitution. A |sprintf()|-like -S option
would avoid this.




TODO: Command substitutions x=$(...) and x=${ ...;} should use a new
string-based I/O stream
Command substitutions x=$(...) and x=${ ...;} should use a new
string-based I/O stream buffer which uses a fixed-size string buffer unless
the following things happen:
- The amount of data overflows the available fixed buffer
- A fd number is requested
- An external command is used which uses this buffer for output (or input)
If one of these conditions happens the buffer needs to be dumped to a file,
the stream switches to this file for I/O.




TODO: Dtrace support for ksh93
- Need to watch functions
- Need to watch variables
- Need to track xtrace output
- Need to track use of regular expressions, e.g. see the exact pattern
  passed to the libast regex engine




TODO: Add support for native PCRE to libast
libast should support native PCRE if available




TODO: Make "ls" a shell builtin
Make "ls" a shell builtin utility




TODO: Add support for "named captures" in regex




TODO: Add support for defining the job id for "read -p" and "print -p"
We should add support for defining the job id for co-process used by
"read -p" and "print -p", e.g. $ print -p%1 # would print to co-process
%1, $ read -p%2 # would read from co-process %2 etc.




TODO: Add option to "read" as counterpart to "print -v nameofarray"
to read arrays. This should be able to be combined with "-C" on demand
to read arrays of compound variables.




TODO: "scanf" builtin
ksh93 should have a "scanf" builtin utility




TODO: function-local traps for signals should save&&replay signals
received duing call of another function
It seems that traps are - like function-local variables - are
statically scoped (assuming this is intended).
This is IMO a good idea... but leads to a question: What should we do
if we expect a signal from someone _but_ must call other shell
functions, maybe a shell function from a shell function library
created by a 3rd-party vendor ?

Example:
-------- snip --------
function ticktick
{
       integer i
       integer tickpid=$1

       for (( i=0 ; i < 100 ; i++ )) ; do
               kill -s RTMIN ${tickpid}
               sleep 0.5
       done
       return 0
}


function x2
{
       /usr/bin/sleep 1
       return 0
}


function x1
{
       # local trap, only valid when signal arrives in this function
       trap 'print tickled ${ticknum}' RTMIN

       ticktick $$ &

       for (( ticknum=0 ; ticknum < 100 ; ticknum++ )) ; do
               if (( ticknum % 2 == 0 )) ; then
                       /usr/bin/sleep 1
               else
                       x2
               fi
       done

       print '#done'
       wait
       print '#really done'

       return 0
}

integer ticknum=0
x1
-------- snip --------

This example creates a child process which fires every 0.5 seconds a
SIGRTMIN signal to the parent process. The parent process itself loops
during this time, calling either /usr/bin/sleep or a seperate function
(with "function" syntax to get a seperate scope) for each iteration of
the loop.
This prints:
-- snip --
tickled 0
tickled 2
tickled 4
tickled 6
tickled 8
tickled 10
tickled 12
tickled 14
tickled 16
tickled 18
-- snip --

AFAIK it may be nice to add an option to "trap" which says: Define
this "trap" to match the current scope but if we call another function
save any signals send during that time and replay them when this shell
function we called returns (unless the function we call itself
establishes an own trap handler for this signal).
The purpose is that no signals end-up being "lost" just because we
have established a function-local trap handler but have to call
another shell function



TODO: Add typeset -M<mapping> to replace typeset -l/-u for character transformations
RFE: Add typeset -M<mapping> where <mapping> is passed to wctrans(3C)
to select a suiteable charatcer mapping like "tolower" and/or "toupper".
This would allow other mappings in non-"C" locales and many mappings
defined for Unicode character sets and mappings for languages like
Chinese, Japanese, Korean, Vietnamese (for example ja_JP.UTF-8 defines
"tojisx0208", "tojkata").
"typeset -l" and "typeset -u" will work as usual but would be implemented internally
via "typeset -M".




TODO: Add regex testsuite module entry for "jspace" character class in ja_JP.UTF-8
~/bin/ksh -c $'export LC_ALL=ja_JP.UTF-8 ; [[ $\'\\u[3000] \' == ~(E)([[:jspace:]])(.*) ]] ; print -v .sh.match'




TODO: libast regex should support [[:<:]] and [[:>:]] used in FreeBSD to
mark begin and end of word boundaries (same as \< and \>)
$ ~/bin/ksh -c '[[ "x " == ~(Elr)\<.*\>[[:space:]] ]] && print true'                                           
true
$ ~/bin/ksh -c '[[ "x " == ~(Elr)[[:<:]].*[[:>:]][[:space:]] ]] && print true'  
true