ksh: State of NOTES and PROJECTS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

ksh: State of NOTES and PROJECTS

Klemens Nanni
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.

If NOTES and PROJECTS stay, I'd be happy to remove/update some of the
topics.

Reply | Threaded
Open this post in threaded view
|

Re: ksh: State of NOTES and PROJECTS

Jeremie Courreges-Anglas-2
On Sat, Jan 06 2018, Klemens Nanni <[hidden email]> 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.


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

Reply | Threaded
Open this post in threaded view
|

Re: ksh: State of NOTES and PROJECTS

Klemens Nanni
On Mon, Jan 08, 2018 at 02:23:48AM +0100, Jeremie Courreges-Anglas wrote:

> On Sat, Jan 06 2018, Klemens Nanni <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: ksh: State of NOTES and PROJECTS

Jeremie Courreges-Anglas-2
On Mon, Jan 08 2018, Klemens Nanni <[hidden email]> wrote:

[...]

> See attached diff for the first NOTES changes.

[...]

> 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, [...]

Looks good, except you give no rationale for moving the FPATH quirk
from "known differences [...] that are not likely to change" to "known
differences [...] that may change".

IIUC ksh93 now documents this behavior:

              FPATH  The search path for function definitions.  The
                     directories in this path are searched for a file with the
                     same name as the function or command when a function with
                     the -u attribute is referenced and when a command is not
                     found.  If an executable file with the name of that
                     command is found, then it is read and executed in the
                     current environment. [...]

(Actually ksh93 doesn't require the file to be executable.)

Right now I'm tempted to leave the FPATH bits as is or to amend them,
not to move them to the "may change later" section.

> 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
>

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: ksh: State of NOTES and PROJECTS

Jeremie Courreges-Anglas-2
On Mon, Jan 08 2018, Jeremie Courreges-Anglas <[hidden email]> wrote:

> On Mon, Jan 08 2018, Klemens Nanni <[hidden email]> wrote:
>
> [...]
>
>> See attached diff for the first NOTES changes.
>
> [...]
>
>> 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, [...]
>
> Looks good, except you give no rationale for moving the FPATH quirk
> from "known differences [...] that are not likely to change" to "known
> differences [...] that may change".
>
> IIUC ksh93 now documents this behavior:
>
>               FPATH  The search path for function definitions.  The
>                      directories in this path are searched for a file with the
>                      same name as the function or command when a function with
>                      the -u attribute is referenced and when a command is not
>                      found.  If an executable file with the name of that
>                      command is found, then it is read and executed in the
>                      current environment. [...]
>
> (Actually ksh93 doesn't require the file to be executable.)
>
> Right now I'm tempted to leave the FPATH bits as is or to amend them,
> not to move them to the "may change later" section.

Another small round of fixes.
- unreadable/setuid scripts... what?
- BUG-REPORTS has been moved to Attic
- s/effect/affect where relevant
- tweak the note about FPATH
- pdksh "understand[s] C integer constants (ie, 0x123, 0177)"

I've been tempted to remove the second paragraph in POSIX sh bugs, but
I don't know whether ksh handles all the details of parameter
expansions.


Index: NOTES
===================================================================
RCS file: /cvs/src/bin/ksh/NOTES,v
retrieving revision 1.15
diff -u -p -r1.15 NOTES
--- NOTES 8 Jan 2018 13:39:06 -0000 1.15
+++ NOTES 8 Jan 2018 14:00:45 -0000
@@ -6,12 +6,10 @@ General features of at&t ksh88 that are
     - signals/traps not cleared during functions.
     - trap DEBUG, local ERR and EXIT traps in functions.
     - ERRNO parameter.
-    - 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
     - the last command of a pipeline is not run in the parent shell
 
-Known bugs (see also BUG-REPORTS and PROJECTS files):
+Known bugs (see also PROJECTS files):
     Variable parsing, Expansion:
  - some specials behave differently when unset (eg, IFS behaves like
   " \t\n") others lose their special meaning.  IFS/PATH taken care of,
@@ -25,9 +23,9 @@ Known bugs (see also BUG-REPORTS and PRO
     Commands,Execution:
  - setting special parameters that have side effects when
   changed/restored (ie, HISTFILE, OPTIND, RANDOM) in front
-  of a command (eg, HISTFILE=/foo/bar echo hi) effects the parent
+  of a command (eg, HISTFILE=/foo/bar echo hi) affects the parent
   shell.  Note that setting other (not so special) parameters
-  does not effect the parent shell.
+  does not affect the parent shell.
  - `echo hi | exec cat -n' causes at&t to exit, `exec echo hi | cat -n'
   does not.  pdksh exits for neither.  Don't think POSIX requires
   an exit, but not sure.
@@ -239,8 +237,8 @@ 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.
+    - undocumented at&t ksh88, documented in ksh93: 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?
@@ -276,9 +274,6 @@ POSIX sh bugs (references are to POSIX 1
   functions don't do the save/restore automatically).  Restoring
   OPTIND is kind of dumb since getopts may have been in the middle
   of parsing a group of flags (eg, -abc).
- - unclear whether arithmetic expressions (eg, $((..))) should
-  understand C integer constants (ie, 0x123, 0177).  at&t ksh doesn't
-  and neither does pdksh.
  - `...` definition (3.6.3) says nothing about backslash followed by
   a newline, which sh and at&t ksh strip out completely.  e.g.,
  $ show-args `echo 'X


--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: ksh: State of NOTES and PROJECTS

Klemens Nanni
On Mon, Jan 08, 2018 at 03:06:32PM +0100, Jeremie Courreges-Anglas wrote:
> On Mon, Jan 08 2018, Jeremie Courreges-Anglas <[hidden email]> wrote:
> > On Mon, Jan 08 2018, Klemens Nanni <[hidden email]> wrote:
> > Looks good, except you give no rationale for moving the FPATH quirk
> > from "known differences [...] that are not likely to change" to "known
> > differences [...] that may change".
I checked ksh88 but not ksh93, my bad.

> > IIUC ksh93 now documents this behavior:
> >
> >               FPATH  The search path for function definitions.  The
> >                      directories in this path are searched for a file with the
> >                      same name as the function or command when a function with
> >                      the -u attribute is referenced and when a command is not
> >                      found.  If an executable file with the name of that
> >                      command is found, then it is read and executed in the
> >                      current environment. [...]
> >
> > (Actually ksh93 doesn't require the file to be executable.)
> >
> > Right now I'm tempted to leave the FPATH bits as is or to amend them,
> > not to move them to the "may change later" section.
>
> Another small round of fixes.
> - unreadable/setuid scripts... what?
> - BUG-REPORTS has been moved to Attic
> - s/effect/affect where relevant
> - tweak the note about FPATH
> - pdksh "understand[s] C integer constants (ie, 0x123, 0177)"
These all look good so far, thanks.

> I've been tempted to remove the second paragraph in POSIX sh bugs, but
> I don't know whether ksh handles all the details of parameter
> expansions.
Tilde expansion is not performed in double quoted words of parameter
expansions:

        $ unset v
        $ echo ${v:=~root} # assigns expanded word
        /root
        $ echo ${v+"~root"} # substitutes unexpanded word
        ~root

Other expansion operators (-, ?, #, ##, %, %%) behave the same. So I'd
say it's safe to remove that, too.

Reply | Threaded
Open this post in threaded view
|

Re: ksh: State of NOTES and PROJECTS

Jeremie Courreges-Anglas-2
On Mon, Jan 08 2018, Klemens Nanni <[hidden email]> wrote:

> On Mon, Jan 08, 2018 at 03:06:32PM +0100, Jeremie Courreges-Anglas wrote:
>> On Mon, Jan 08 2018, Jeremie Courreges-Anglas <[hidden email]> wrote:
>> > On Mon, Jan 08 2018, Klemens Nanni <[hidden email]> wrote:
>> > Looks good, except you give no rationale for moving the FPATH quirk
>> > from "known differences [...] that are not likely to change" to "known
>> > differences [...] that may change".
> I checked ksh88 but not ksh93, my bad.
>
>> > IIUC ksh93 now documents this behavior:
>> >
>> >               FPATH  The search path for function definitions.  The
>> >                      directories in this path are searched for a file with the
>> >                      same name as the function or command when a function with
>> >                      the -u attribute is referenced and when a command is not
>> >                      found.  If an executable file with the name of that
>> >                      command is found, then it is read and executed in the
>> >                      current environment. [...]
>> >
>> > (Actually ksh93 doesn't require the file to be executable.)
>> >
>> > Right now I'm tempted to leave the FPATH bits as is or to amend them,
>> > not to move them to the "may change later" section.
>>
>> Another small round of fixes.
>> - unreadable/setuid scripts... what?
>> - BUG-REPORTS has been moved to Attic
>> - s/effect/affect where relevant
>> - tweak the note about FPATH
>> - pdksh "understand[s] C integer constants (ie, 0x123, 0177)"
> These all look good so far, thanks.

ack, I'll commit my diff then.

>> I've been tempted to remove the second paragraph in POSIX sh bugs, but
>> I don't know whether ksh handles all the details of parameter
>> expansions.
> Tilde expansion is not performed in double quoted words of parameter
> expansions:
>
> $ unset v
> $ echo ${v:=~root} # assigns expanded word
> /root
> $ echo ${v+"~root"} # substitutes unexpanded word
> ~root
>
> Other expansion operators (-, ?, #, ##, %, %%) behave the same. So I'd
> say it's safe to remove that, too.

Yeah, but maybe a more solid approach would be to remove this entry from
NOTES/PROJECTS only when we have good regress tests?  AFAIK here we only
have a few (unclass1.t).  Just a suggestion, I'm not trying to push this
as a required step whenever we want to amend NOTES/PROJECTS.

I have added basic regress tests for hex/octal notation and POSIX
character classes btw, feedback welcome.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE