PR/52302 CVS commit: [netbsd-8] src/bin

["Soren Jacobsen" <snj%netbsd.org@localhost>]

The following reply was made to PR bin/52302; it has been noted by GNATS.

From: "Soren Jacobsen" <snj%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/52302 CVS commit: [netbsd-8] src/bin
Date: Sun, 23 Jul 2017 14:58:14 +0000

 Module Name:	src
 Committed By:	snj
 Date:		Sun Jul 23 14:58:14 UTC 2017
 
 Modified Files:
 	src/bin/kill [netbsd-8]: kill.c
 	src/bin/sh [netbsd-8]: Makefile arith_token.c arith_tokens.h
 	    arithmetic.c arithmetic.h cd.c error.c eval.c exec.c exec.h
 	    expand.c expand.h histedit.c input.c input.h jobs.c main.c
 	    memalloc.c memalloc.h mknodenames.sh mkoptions.sh myhistedit.h
 	    nodetypes option.list parser.c parser.h redir.c redir.h sh.1
 	    shell.h show.c show.h syntax.c syntax.h trap.c var.c var.h
 	src/bin/sh/bltin [netbsd-8]: bltin.h
 
 Log Message:
 Pull up following revision(s) (requested by kre in ticket #103):
 	bin/kill/kill.c: 1.28
 	bin/sh/Makefile: 1.111-1.113
 	bin/sh/arith_token.c: 1.5
 	bin/sh/arith_tokens.h: 1.2
 	bin/sh/arithmetic.c: 1.3
 	bin/sh/arithmetic.h: 1.2
 	bin/sh/bltin/bltin.h: 1.15
 	bin/sh/cd.c: 1.49-1.50
 	bin/sh/error.c: 1.40
 	bin/sh/eval.c: 1.142-1.151
 	bin/sh/exec.c: 1.49-1.51
 	bin/sh/exec.h: 1.26
 	bin/sh/expand.c: 1.113-1.119
 	bin/sh/expand.h: 1.23
 	bin/sh/histedit.c: 1.49-1.52
 	bin/sh/input.c: 1.57-1.60
 	bin/sh/input.h: 1.19-1.20
 	bin/sh/jobs.c: 1.86-1.87
 	bin/sh/main.c: 1.71-1.72
 	bin/sh/memalloc.c: 1.30
 	bin/sh/memalloc.h: 1.17
 	bin/sh/mknodenames.sh: 1.4
 	bin/sh/mkoptions.sh: 1.3-1.4
 	bin/sh/myhistedit.h: 1.12-1.13
 	bin/sh/nodetypes: 1.16-1.18
 	bin/sh/option.list: 1.3-1.5
 	bin/sh/parser.c: 1.133-1.141
 	bin/sh/parser.h: 1.22-1.23
 	bin/sh/redir.c: 1.58
 	bin/sh/redir.h: 1.24
 	bin/sh/sh.1: 1.149-1.159
 	bin/sh/shell.h: 1.24
 	bin/sh/show.c: 1.43-1.47
 	bin/sh/show.h: 1.11
 	bin/sh/syntax.c: 1.4
 	bin/sh/syntax.h: 1.8
 	bin/sh/trap.c: 1.41
 	bin/sh/var.c: 1.56-1.65
 	bin/sh/var.h: 1.29-1.35
 An initial attempt at implementing LINENO to meet the specs.
 Aside from one problem (not too hard to fix if it was ever needed) this version
 does about as well as most other shell implementations when expanding
 $((LINENO)) and better for ${LINENO} as it retains the "LINENO hack" for the
 latter, and that is very accurate.
 Unfortunately that means that ${LINENO} and $((LINENO)) do not always produce
 the same value when used on the same line (a defect that other shells do not
 share - aside from the FreeBSD sh as it is today, where only the LINENO hack
 exists and so (like for us before this commit) $((LINENO)) is always either
 0, or at least whatever value was last set, perhaps by
 	LINENO=${LINENO}
 which does actually work ... for that one line...)
 This could be corrected by simply removing the LINENO hack (look for the string
 LINENO in parser.c) in which case ${LINENO} and $((LINENO)) would give the
 same (not perfectly accurate) values, as do most other shells.
 POSIX requires that LINENO be set before each command, and this implementation
 does that fairly literally - except that we only bother before the commands
 which actually expand words (for, case and simple commands).   Unfortunately
 this forgot that expansions also occur in redirects, and the other compound
 commands can also have redirects, so if a redirect on one of the other compound
 commands wants to use the value of $((LINENO)) as a part of a generated file
 name, then it will get an incorrect value.  This is the "one problem" above.
 (Because the LINENO hack is still enabled, using ${LINENO} works.)
 This could be fixed, but as this version of the LINENO implementation is just
 for reference purposes (it will be superseded within minutes by a better one)
 I won't bother.  However should anyone else decide that this is a better choice
 (it is probably a smaller implementation, in terms of code & data space then
 the replacement, but also I would expect, slower, and definitely less accurate)
 this defect is something to bear in mind, and fix.
 This version retains the *BSD historical practice that line numbers in functions
 (all functions) count from 1 from the start of the function, and elsewhere,
 start from 1 from where the shell started reading the input file/stream in
 question.  In an "eval" expression the line number starts at the line of the
 "eval" (and then increases if the input is a multi-line string).
 Note: this version is not documented (beyond as much as LINENO was before)
 hence this slightly longer than usual commit message.
 A better LINENO implementation.   This version deletes (well, #if 0's out)
 the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)).
 (Code to invert the LINENO hack when required, like when de-compiling the
 execution tree to provide the "jobs" command strings, is still included,
 that can be deleted when the LINENO hack is completely removed - look for
 refs to VSLINENO throughout the code.  The var funclinno in parser.c can
 also be removed, it is used only for the LINENO hack.)
 This version produces accurate results: $((LINENO)) was made as accurate
 as the LINENO hack made ${LINENO} which is very good.  That's why the
 LINENO hack is not yet completely removed, so it can be easily re-enabled.
 If you can tell the difference when it is in use, or not in use, then
 something has broken (or I managed to miss a case somewhere.)
 The way that LINENO works is documented in its own (new) section in the
 man page, so nothing more about that, or the new options, etc, here.
 This version introduces the possibility of having a "reference" function
 associated with a variable, which gets called whenever the value of the
 variable is required (that's what implements LINENO).  There is just
 one function pointer however, so any particular variable gets at most
 one of the set function (as used for PATH, etc) or the reference function.
 The VFUNCREF bit in the var flags indicates which func the variable in
 question uses (if any - the func ptr, as before, can be NULL).
 I would not call the results of this perfect yet, but it is close.
 Unbreak (at least) i386 build .... I have no idea why this built for me on
 amd64 (problem was missing prototype for snprintf witout <stdio.h>)
 While here, add some (DEBUG mode only) tracing that proved useful in
 solving another problem.
 Set the line number before expanding args, not after.   As the line_number
 would have usually been set earlier, this change is mostly an effective
 no-op, but it is better this way (just in case) - not observed to have
 caused any problems.
 Undo some over agressive fixes for a (pre-commit) bug that did not
 need these changes to be fixed - and these cause problems in another
 absurd use case.   Either of these issues is unlikely to be seen by
 anyone who isn't an idiot masochist...
 PR bin/52280
 removescapes_nl in expari() even when not quoted,
 CRTNONL's appear regardless of quoting (unlike CTLESC).
 New sentence, new line. Whitespace.
 Improve the (new) LINENO section, markup changes (with thanks to wiz@ for
 assistace) and some better wording in a few placed.
 I am an idiot...  revert the previous unintended commit.
 Remove some left over baggage from the LINENO v1 implementation that
 didn't get removed with v2, and should have.   This would have had
 (I think, without having tested it) one very minor effect on the way
 LINENO worked in the v2 implementation, but my guess is it would have
 taken a long time before anyone noticed...
 Correct spelling in comments of DEBUG only code...
 (Perhaps) temporary fix to pkgtools (cwrappers) build (configure).
 Expanding  `` containing \ \n sequences looks to have been giving
 problems.   I don't think this is the correct fix, but it will do
 no worse harm than (perhaps) incorrectly calculating LINENO in this
 kind of (rare) circumstance.   I'll look and see if there should be
 a better fix later.
 s/volatile/const/ -- wonderful how opposites attract like this.
 NFC (normal use) - DEBUG only change, when showing empty arg list don't
 omit terminating \n.
 Free stack memory in a couple of obscure cases where it wasn't
 being done (one in probably dead code that is never compiled, the other
 in a very rare error case.)   Since it is stack memory it wasn't lost
 in any case, just held longer than needed.
 Many internal memory management type fixes.
 PR bin/52302   (core dump with interactive shell, here doc and error
 on same line) is fixed.   (An old bug.)
 echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )"
 consistently prints 1002 lines (x, 1000 empty ones, then y) as it should
 (And you don't want to know what it did before, or why.) (Another old one.)
 (Recently added) Problems with ~ expansion fixed (mem management related).
 Proper fix for the cwrappers configure problem (which includes the quick
 fix that was done earlier, but extends upon that to be correct). (This was
 another newly added problem.)
 And the really devious (and rare) old bug - if STACKSTRNUL() needs to
 allocate a new buffer in which to store the \0, calculate the size of
 the string space remaining correctly, unlike when SPUTC() grows the
 buffer, there is no actual data being stored in the STACKSTRNUL()
 case - the string space remaining was calculated as one byte too few.
 That would be harmless, unless the next buffer also filled, in which
 case it was assumed that it was really full, not one byte less, meaning
 one junk char (a nul, or anything) was being copied into the next (even
 bigger buffer) corrupting the data.
 Consistent use of stalloc() to allocate a new block of (stack) memory,
 and grabstackstr() to claim a block of (stack) memory that had already
 been occupied but not claimed as in use.  Since grabstackstr is implemented
 as just a call to stalloc() this is a no-op change in practice, but makes
 it much easier to comprehend what is really happening.  Previous code
 sometimes used stalloc() when the use case was really for grabstackstr().
 Change grabstackstr() to actually use the arg passed to it, instead of
 (not much better than) guessing how much space to claim,
 More care when using unstalloc()/ungrabstackstr() to return space, and in
 particular when the stack must be returned to its previous state, rather than
 just returning no-longer needed space, neither of those work.  They also don't
 work properly if there have been (really, even might have been) any stack mem
 allocations since the last stalloc()/grabstackstr().   (If we know there
 cannot have been then the alloc/release sequence is kind of pointless.)
 To work correctly in general we must use setstackmark()/popstackmark() so
 do that when needed.  Have those also save/restore the top of stack string
 space remaining.
 	[Aside: for those reading this, the "stack" mentioned is not
 	in any way related to the thing used for maintaining the C
 	function call state, ie: the "stack segment" of the program,
 	but the shell's internal memory management strategy.]
 More comments to better explain what is happening in some cases.
 Also cleaned up some hopelessly broken DEBUG mode data that were
 recently added (no effect on anyone but the poor semi-human attempting
 to make sense of it...).
 User visible changes:
 Proper counting of line numbers when a here document is delimited
 by a multi-line end-delimiter, as in
 	cat << 'REALLY
 	END'
 	here doc line 1
 	here doc line 2
 	REALLY
 	END
 (which is an obscure case, but nothing says should not work.)  The \n
 in the end-delimiter of the here doc (the last one) was not incrementing
 the line number, which from that point on in the script would be 1 too
 low (or more, for end-delimiters with more than one \n in them.)
 With tilde expansion:
 	unset HOME; echo ~
 changed to return getpwuid(getuid())->pw_home instead of failing (returning ~)
 POSIX says this is unspecified, which makes it difficult for a script to
 compensate for being run without HOME set (as in env -i sh script), so
 while not able to be used portably, this seems like a useful extension
 (and is implemented the same way by some other shells).
 Further, with
 	HOME=; printf %s ~
 we now write nothing (which is required by POSIX - which requires ~ to
 expand to the value of $HOME if it is set) previously if $HOME (in this
 case) or a user's directory in the passwd file (for ~user) were a null
 STRING, We failed the ~ expansion and left behind '~' or '~user'.
 Changed the long name for the -L option from lineno_fn_relative
 to local_lineno as the latter seemed to be marginally more popular,
 and perhaps more importantly, is the same length as the peviously
 existing quietprofile option, which means the man page indentation
 for the list of options can return to (about) what it was before...
 (That is, less indented, which means more data/line, which means less
 lines of man page - a good thing!)
 Cosmetic changes to variable flags - make their values more suited
 to my delicate sensibilities...  (NFC).
 Arrange not to barf (ever) if some turkey makes _ readonly.  Do this
 by adding a VNOERROR flag that causes errors in var setting to be
 ignored (intended use is only for internal shell var setting, like of "_").
 (nb: invalid var name errors ignore this flag, but those should never
 occur on a var set by the shell itself.)
 From FreeBSD: don't simply discard memory if a variable is not set for
 any reason (including because it is readonly) if the var's value had
 been malloc'd.  Free it instead...
 NFC - DEBUG changes, update this to new TRACE method.
 KNF - white space and comment formatting.
 NFC - DEBUG mode only change - convert this to the new TRACE() format.
 NFC - DEBUG mode only change - complete a change made earlier (marking
 the line number when included in the trace line tag to show whether it
 comes from the parser, or the elsewhere as they tend to be quite different).
 Initially only one case was changed, while I pondered whether I liked it
 or not.  Now it is all done...   Also when there is a line tag at all,
 always include the root/sub-shell indicator character, not only when the
 pid is included.
 NFC: DEBUG related comment change - catch up with reality.
 NFC: DEBUG mode only change.  Fix botched cleanup of one TRACE().
 "b" more forgiving when sorting options to allow reasonable (and intended)
 flexibility in option.list format.   Changes nothing for current option.list.
 Now that excessive use of STACKSTRNUL has served its purpose (well, accidental
 purpose) in exposing the bug in its implementation, go back to not using
 it when not needed for DEBUG TRACE purposes.   This change should have no
 practical effect on either a DEBUG shell (where the STACKSTRNUL() calls
 remain) or a non DEBUG shell where they are not needed.
 Correct the initial line number used for processing -c arg strings.
 (It was inheriting the value from end of profile file processing) - I didn't
 notice before as I usually test with empty or no profile files to avoid
 complications.   Trivial change which should have very limited impact.
 Fix from FreeBSD (applied there in July 2008...)
 Don't dump core with input like sh -c 'x=; echo >&$x' - that is where
 the word after a >& or <& redirect expands to nothing at all.
 Another fix from FreeBSD (this one from April 2009).
 When processing a string (as in eval, trap, or sh -c) don't allow
 trailing \n's to destroy the exit status of the last command executed.
 That is:
 	sh -c 'false
 	'
 	echo $?
 should produce 1, not 0.
 It is amazing what nonsense appears to work sometimes... (all my nonsense too!)
 Two bugs here, one benign because of the way the script is used.
 The other hidden by NetBSD's sort being stable, and the data not really
 requiring sorting at all...
 So as it happens these fixes change nothing, but they are needed anyway.
 (The contents of the generated file are only used in DEBUG shells, so
 this is really even less important than it seems.)
 Another ancient (highly improbable) bug bites the dust.   This one
 caused by incorrect macro usage (ie: using the wrong one) which has
 been in the sources since version 1.1 (ie: forever).
 Like the previous (STACKSTRNUL) bug, the probability of this one
 actually occurring has been infinitesimal but the LINENO code increases
 that to infinitesimal and a smidgen... (or a few, depending upon usage).
 Still, apparently that was enough, Kamil Rytarowski discovered that the
 zsh configure script (damn competition!) managed to trigger this problem.
 source .editrc after we initialize so that commands persist!
 Make arg parsing in kill POSIX compatible with POSIX (XBD 2.12) by
 parsing the way getopt(3) would, if only it could handle the (required)
 -signumber and -signame options.  This adds two "features" to kill,
 -ssigname and -lstatus now work (ie: one word with all of the '-', the
 option letter, and its value) and "--" also now works (kill -- -pid1 pid2
 will not attempt to send the pid1 signal to pid2, but rather SIGTERM
 to the pid1 process group and pid2).  It is still the case that (apart
 from --) at most 1 option is permitted (-l, -s, -signame, or -signumber.)
 Note that we now have an ambiguity, -sname might mean "-s name" or
 send the signal "sname" - if one of those turns out to be valid, that
 will be accepted, otherwise the error message will indicate that "sname"
 is not a valid signal name, not that "name" is not.   Keeping the "-s"
 and signal name as separate words avoids this issue.
 Also caution: should someone be weird enough to define a new signal
 name (as in the part after SIG) which is almost the same name as an
 existing name that starts with 'S' by adding an extra 'S' prepended
 (eg: adding a SIGSSYS) then the ambiguity problem becomes much worse.
 In that case "kill -ssys" will be resolved in favour of the "-s"
 flag being used (the more modern syntax) and would send a SIGSYS, rather
 that a SIGSSYS.    So don't do that.
 While here, switch to using signalname(3) (bye bye NSIG, et. al.), add
 some constipation, and show a little pride in formatting the signal names
 for "kill -l" (and in the usage when appropriate -- same routine.)   Respect
 COLUMNS (POSIX XBD 8.3) as primary specification of the width (terminal width,
 not number of columns to print) for kill -l, a very small value for COLUMNS
 will cause kill -l output to list signals one per line, a very large
 value will cause them all to be listed on one line.) (eg: "COLUMNS=1 kill -l")
 TODO: the signal printing for "trap -l" and that for "kill -l"
 should be switched to use a common routine (for the sh builtin versions.)
 All changes of relevance here are to bin/kill - the (minor) changes to bin/sh
 are only to properly expose the builtin version of getenv(3) so the builtin
 version of kill can use it (ie: make its prototype available.)
 Properly support EDITRC - use it as (naming) the file when setting
 up libedit, and re-do the config whenever EDITRC is set.
 Get rid of workarounds for ancient groff html backend.
 Simplify macro usage.
 Make one example more like a real world possibility (it still isn't, but
 is closer) - though the actual content is irrelevant to the point being made.
 Add literal prompt support this allows one to do:
 CA="$(printf '\1')"
 PS1="${CA}$(tput bold)${CA}\$${CA}$(tput sgr0)${CA} "
 Now libedit supports embedded mode switch sequence, improve sh
 support for them (adds PSlit variable to set the magic character).
 NFC: DEBUG only change - provide an externally visible (to the DEBUG sh
 internals) interface to one of the internal (private to trace code) functions
 Include redirections in trace output from "set -x"
 Implement PS1, PS2 and PS4 expansions (variable expansions, arithmetic
 expansions, and if enabled by the promptcmds option, command substitutions.)
 Implement a bunch of new shell environment variables. many mostly useful
 in prompts when expanded at prompt time, but all available for general use.
 Many of the new ones are not available in SMALL shells (they work as normal
 if assigned, but the shell does not set or use them - and there is no magic
 in a SMALL shell (usually for install media.))
 Omnibus manual update for prompt expansions and new variables.  Throw in
 some random cleanups as a bonus.
 Correct a markup typo (why did I not see this before the prev commit??)
 Sort options (our default is 0..9AaBbZz).
 Fix markup problems and a typo.
 Make $- list flags in the same order they appear in sh(1)
 Do a better job of detecting the error in pkgsrc/devel/libbson-1.6.3's
 configure script, ie: $(( which is intended to be a sub-shell in a
 command substitution, but is an arith subst instead, it needs to be
 written $( ( to do as intended.   Instead of just blindly carrying on to
 find the missing )) somewhere, anywhere, give up as soon as we have seen
 an unbalanced ')' that isn't immediately followed by another ')' which
 in a valid arith subst it always would be.
 While here, there has been a comment in the code for quite a while noting a
 difference in the standard between the text descr & grammar when it comes to
 the syntax of case statements.   Add more comments to explain why parsing it
 as we do is in fact definitely the correct way (ie: the grammar wins arguments
 like this...).
 DEBUG and white space changes only.   Convert TRACE() calls for DEBUg mode
 to the new style.   NFC (when not debugging sh).
 Mostly DEBUG and white space changes.   Convert DEEBUG TRACE() calls to
 the new format.   Also #if 0 a function definition that is used nowhere.
 While here, change the function of pushfile() slightly - it now sets
 the buf pointer in the top (new) input descriptor to NULL, instead of
 simply leaving it - code that needs a buffer always (before and after)
 must malloc() one and assign it after the call.  But code which does not
 (which will be reading from a string or similar) now does not have to
 explicitly set it to NULL (cleaner interface.)   NFC intended (or observed.)
 DEBUG changes: convert DEBUG TRACE() calls to new format.
 ALso, cause exec failures to always cause the shell to exit with
 status 126 or 127, whatever the cause.  127 is intended for lookup
 failures (and is used that way), 126 is used for anything else that
 goes wrong (as in several other shells.)  We no longer use 2 (more easily
 confused with an exit status of the command exec'd) for shell exec failures.
 DEBUG only changes.  Convert the TRACE() calls in the remaining files
 that still used it to the new format.   NFC.
 Fix a reference after free (and consequent nonsense diagnostic for
 attempts to set readonly variables) I added in 1.60 by incompletely
 copying the FreeBSD fix for the lost memory issue.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.27 -r1.27.36.1 src/bin/kill/kill.c
 cvs rdiff -u -r1.110 -r1.110.2.1 src/bin/sh/Makefile
 cvs rdiff -u -r1.4 -r1.4.2.1 src/bin/sh/arith_token.c
 cvs rdiff -u -r1.1 -r1.1.8.1 src/bin/sh/arith_tokens.h \
     src/bin/sh/arithmetic.h
 cvs rdiff -u -r1.2 -r1.2.2.1 src/bin/sh/arithmetic.c src/bin/sh/mkoptions.sh \
     src/bin/sh/option.list
 cvs rdiff -u -r1.47.6.1 -r1.47.6.2 src/bin/sh/cd.c
 cvs rdiff -u -r1.39 -r1.39.8.1 src/bin/sh/error.c
 cvs rdiff -u -r1.140.2.1 -r1.140.2.2 src/bin/sh/eval.c
 cvs rdiff -u -r1.47.2.1 -r1.47.2.2 src/bin/sh/exec.c
 cvs rdiff -u -r1.24.8.1 -r1.24.8.2 src/bin/sh/exec.h
 cvs rdiff -u -r1.110.2.1 -r1.110.2.2 src/bin/sh/expand.c
 cvs rdiff -u -r1.22 -r1.22.2.1 src/bin/sh/expand.h
 cvs rdiff -u -r1.48 -r1.48.8.1 src/bin/sh/histedit.c
 cvs rdiff -u -r1.56 -r1.56.2.1 src/bin/sh/input.c
 cvs rdiff -u -r1.18 -r1.18.2.1 src/bin/sh/input.h
 cvs rdiff -u -r1.85 -r1.85.2.1 src/bin/sh/jobs.c
 cvs rdiff -u -r1.70 -r1.70.2.1 src/bin/sh/main.c
 cvs rdiff -u -r1.29 -r1.29.62.1 src/bin/sh/memalloc.c
 cvs rdiff -u -r1.16 -r1.16.2.1 src/bin/sh/memalloc.h
 cvs rdiff -u -r1.3 -r1.3.8.1 src/bin/sh/mknodenames.sh
 cvs rdiff -u -r1.11 -r1.11.36.1 src/bin/sh/myhistedit.h
 cvs rdiff -u -r1.15 -r1.15.2.1 src/bin/sh/nodetypes
 cvs rdiff -u -r1.132 -r1.132.2.1 src/bin/sh/parser.c
 cvs rdiff -u -r1.21 -r1.21.8.1 src/bin/sh/parser.h
 cvs rdiff -u -r1.57 -r1.57.2.1 src/bin/sh/redir.c
 cvs rdiff -u -r1.23 -r1.23.2.1 src/bin/sh/redir.h src/bin/sh/shell.h
 cvs rdiff -u -r1.146.2.2 -r1.146.2.3 src/bin/sh/sh.1
 cvs rdiff -u -r1.42 -r1.42.2.1 src/bin/sh/show.c
 cvs rdiff -u -r1.10 -r1.10.2.1 src/bin/sh/show.h
 cvs rdiff -u -r1.3 -r1.3.26.1 src/bin/sh/syntax.c
 cvs rdiff -u -r1.7 -r1.7.2.1 src/bin/sh/syntax.h
 cvs rdiff -u -r1.40 -r1.40.2.1 src/bin/sh/trap.c
 cvs rdiff -u -r1.55 -r1.55.2.1 src/bin/sh/var.c
 cvs rdiff -u -r1.28 -r1.28.8.1 src/bin/sh/var.h
 cvs rdiff -u -r1.14 -r1.14.8.1 src/bin/sh/bltin/bltin.h
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.