On Mon, Jan 08, 2018 at 02:23:48AM +0100, Jeremie Courreges-Anglas wrote:
> On Sat, Jan 06 2018, Klemens Nanni <k...@posteo.org> wrote:
> > Looking at the CVS log one can see that other legacies such as ChangeLog
> > have already been zapped. NOTES and PROJECTS have seen sporadic minor
> > updates since import and still list valid topics, but they lack other
> > long overdue correcttions. For example:
> >
> > - support for POSIX character class globbing was done in 2009
> > - EASY and COMPLEX history code got zapped in 2004
> > - `time' has a -p option since pdksh-5.2.14 from 1999
> >
> > Documentation is nice but wrong/outdated documentation sucks, so should
> > NOTES and PROJECTS be further maintained or removed as well?
> >
> > I prefer keeping them as of now since they're quite informative when
> > digging deeper into the sources. On the other hand, maintenance requires
> > history and knowledge of other shells when it comes to differences
> > between them - I'm clearly out here and cannot judge the amount of work
> > on that part.
> >
> > What do you think? Feedback is greatly appreciated.
> 
> NOTES is quite dense indeed, I think it can have value.
> 
> > If NOTES and PROJECTS stay, I'd be happy to remove/update some of the
> > topics.
> 
> Here's a first diff to kill the most obvious entries in PROJECTS.  The
> next steps will probably take more time.
Indeed.

See attached diff for the first NOTES changes.

> Index: PROJECTS
> ===================================================================
> RCS file: /d/cvs/src/bin/ksh/PROJECTS,v
> retrieving revision 1.8
> diff -u -p -r1.8 PROJECTS
> --- PROJECTS  14 Sep 2015 09:42:33 -0000      1.8
> +++ PROJECTS  8 Jan 2018 01:12:43 -0000
> @@ -22,31 +22,11 @@ Things to be done in pdksh (see also the
>  
>        (ulimit also needs to be examined to check that it fits the posix 
> style)
>  
> -    * test suite
> -      Ideally, as the builtin utilities are being POSIXized, short tests
> -      should be written to be used in regression testing.  The tests
> -      directory contains some tests, but many more need to be written.
> -
> -    * internationalization
> -      Need to handle with the LANG and LC_* environment variables.  This
> -      involves changes to ensure <ctype.h> macros are being used (currently
> -      uses its own macros in many places), figuring out how to deal with
> -      bases (for integer arithmetic, eg, 12#1A), and (the nasty one) doing
> -      string look ups for error messages, etc..  It probably isn't worth
> -      translating strings to other languages yet as the code is likely
> -      to change a lot in the near future, but it would be good to have the
> -      code set up so string tables can be used.
> -
>      * trap code
>       * add the DEBUG trap.
>       * fix up signal handling code.  In particular, fatal vs tty signals,
>         have signal routine to call to check for pending/fatal traps, etc.
>  
> -    * parsing
> -     * the time keyword needs to be hacked to accept options (!) since
> -       POSIX says it shall accept the -p option and must skip a -- argument
> -       (end of options).  Yuck.
> -
>      * lexing
>        the lexing may need a re-write since it currently doesn't parse $( .. 
> ),
>        $(( .. )), (( ... )) properly.
> @@ -68,30 +48,10 @@ Things to be done in pdksh (see also the
>        in general, treatment of OPTIND/OPTARG,
>  
>      * history
> -      There are two versions of the history code, COMPLEX_HISTORY and
> -      EASY_HISTORY, which need to be merged.  COMPLEX does at&t style history
> -      where the history file is written after each command and checked when
> -      ever looking through the history (in case another shell has added
> -      something).  EASY simply reads the history file at startup and writes
> -      it before exiting.
> -     * re-write the COMPLEX_HISTORY code so mmap() not needed (currently
> -       can't be used on machines without mmap()).
> -     * Add multiline knowledge to COMPLEX_HISTORY (see EASY_HISTORY
> -       stuff).
> -     * change COMPLEX_HISTORY code so concurrent history files are
> -       controlled by an option (set -o history-concurrent?).  Delete
> -       the EASY_HISTORY code.
> +     * Add multiline knowledge
>       * bring history code up to POSIX standards (see POSIX description
>         of fc, etc.).
>  
> -    * documentation
> -      Some sort of tutorial with examples would be good.  Texinfo is probably
> -      the best medium for this.  Also, the man page could be converted to
> -      texinfo (if the tutorial and man page  are put in the same texinfo
> -      page, they should be somewhat distinct - i.e., the tutorial should
> -      be a separate thread - but there should be cross references between the
> -      two).
> -
>      * miscellaneous
>       * POSIX specifies what happens when various kinds of errors occur
>         in special built-ins commands vs regular commands (builtin or
> @@ -104,8 +64,3 @@ Things to be done in pdksh (see also the
>       * merge the emacs and vi code (should reduce the size of the shell and
>         make maintenance easier); handle SIGWINCH while editing a line.
>         [John Rochester is working on the merge]
> -
> -     * add POSIX globbing (eg, [[:alnum:]]), see POSIX.2:2.8.3.2.
> -
> -     * teach shf_vfprintf() about long long's (%lld); also make %p use
> -       long longs if appropriate.
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> 
That's what I had so far, except for the "multiline knowledge"
bits that are already in NOTES.

Regarding "POSIX sh questions", we should probably unreference the 1992
standard.

POSIX.1-2008, 2.6.2 Parameter Expansion:

        In each case that a value of word is needed (based on the state
        of parameter, as described below), word shall be subjected to
        tilde expansion, [...]

diff --git a/bin/ksh/NOTES b/bin/ksh/NOTES
index 5fc1080bfbd..af0f1230af9 100644
--- a/bin/ksh/NOTES
+++ b/bin/ksh/NOTES
@@ -6,7 +6,6 @@ General features of at&t ksh88 that are not (yet) in pdksh:
     - signals/traps not cleared during functions.
     - trap DEBUG, local ERR and EXIT traps in functions.
     - ERRNO parameter.
-    - doesn't have posix file globbing (eg, [[:alpha:]], etc.).
     - use of an `agent' to execute unreadable/setuid/setgid shell scripts
       (don't ask).
     - read/select aren't hooked in to the command line editor
@@ -34,7 +33,6 @@ Known bugs (see also BUG-REPORTS and PROJECTS files):
          an exit, but not sure.
        - `echo foo | read bar; echo $bar' prints foo in at&t ksh, nothing
          in pdksh (ie, the read is done in a separate process in pdksh).
-    Misc:
 
 Known problems not caused by ksh:
     - after stoping a job, emacs/vi is not re-entered.  Hitting return
@@ -80,6 +78,8 @@ Known differences between pdksh & at&t ksh (that may change)
          in pdksh it changes.
        - Value of LINENO after it has been set by the script in one file
          is bizarre when used in another file.
+    - FPATH is searched after PATH if no executable is found, even if
+      typeset -uf wasn't used. Documented in pdksh but not at&t.
 
 Known differences between pdksh & at&t ksh (that are not likely to change)
     - at&t ksh seems to catch or ignore SIGALRM - pdksh dies upon receipt
@@ -241,23 +241,19 @@ Oddities in ksh (pd & at&t):
     - when tracing (set -x), and a command's stderr is redirected, the trace
       output is also redirected. so "set -x; echo foo 2> /tmp/O > /dev/null"
       will create /tmp/foo with the lines "+ > /dev/null" and "+ echo foo".
-    - undocumented at&t ksh feature: FPATH is searched after PATH if no
-      executable is found, even if typeset -uf wasn't used.
 
 POSIX sh questions (references are to POSIX 1003.2-1992)
        - arithmetic expressions: how are empty expressions treated?
          (eg, echo $((  ))).  at&t ksh (and now pdksh) echo 0.
          Same question goes for `test "" -eq 0' - does this generate an error
          or, if not, what is the exit code?
-       - should tilde expansion occur after :'s in the word part of ${..=..}?
-         (me thinks it should)
        - if a signal is received during the execution of a built-in,
          does the builtin command exit or the whole shell?
        - is it legal to execute last command of pipeline in current
          execution environment (eg, can "echo foo | read bar" set
          bar?)
        - what action should be taken if there is an error doing a dup due
-         to system limits (eg, not enough feil destriptors): is this
+         to system limits (eg, not enough file destriptors): is this
          a "redirection error" (in which case a script will exit iff the
          error occured while executing a special built-in)?
          IMHO, shell should exit script.  Couldn't find a blanket statement

Reply via email to