On Mon, Jan 08 2018, Klemens Nanni <k...@posteo.org> 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 via email to