On Mon, Jan 08 2018, Klemens Nanni <k...@posteo.org> wrote:
> On Mon, Jan 08, 2018 at 03:06:32PM +0100, Jeremie Courreges-Anglas wrote:
>> On Mon, Jan 08 2018, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote:
>> > On Mon, Jan 08 2018, Klemens Nanni <k...@posteo.org> 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

Reply via email to