CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: snj Date: Wed Aug 9 05:35:19 UTC 2017 Modified Files: src/bin/sh [netbsd-8]: input.c parser.c Log Message: Pull up following revision(s) (requested by kre in ticket #199): bin/sh/input.c: revision 1.61 bin/sh/parser.c: revision 1.143 PR bin/52458 Avoid mangling history when editing is enabled, and the prompt contains a \n Also, allow empty input lines into history when they are being appended to a previous (partial) command (but not when they would just make an empty entry) . For all the gory details, see the PR. Note nothing here actually makes prompts containing \n work correctly when editing is enabled, that's a libedit issue, which will be addressed some other time. To generate a diff of this commit: cvs rdiff -u -r1.56.2.1 -r1.56.2.2 src/bin/sh/input.c cvs rdiff -u -r1.132.2.1 -r1.132.2.2 src/bin/sh/parser.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src
Committed By: martin
Date: Thu Aug 31 11:43:44 UTC 2017
Modified Files:
src/bin/sh [netbsd-8]: var.c
Log Message:
Pull up following revision(s) (requested by kre in ticket #250):
bin/sh/var.c: revision 1.67
Fix a bug noticed by Soren Jacobsen running the netbsd-6-0 build.sh which
causes a core dump in some exotic circumstances (when restoring local
variables when a function returns). ("build.sh makewrapper" exposed it.)
This was introduced in 1.63 - not as part of the substance of that
change (addition) but as an unrelated "must be the right thing to do"
cleanup, which wasn't...
To generate a diff of this commit:
cvs rdiff -u -r1.55.2.1 -r1.55.2.2 src/bin/sh/var.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src
Committed By: snj
Date: Wed Oct 25 06:51:36 UTC 2017
Modified Files:
src/bin/sh [netbsd-8]: expand.c sh.1
Log Message:
Pull up following revision(s) (requested by kre in ticket #310):
bin/sh/expand.c: revision 1.121
bin/sh/sh.1: revision 1.167 via patch
Three fixes and a change to ~ expansions
1. A serious bug introduced 3 1/2 months ago (approx) (rev 1.116) which
broke all but the simple cases of ~ expansions is fixed (amazingly,
given the magnitude of this problem, no-one noticed!)
2. An ancient bug (probably from when ~ expansion was first addedin 1994, and
certainly is in NetBSD-6 vintage shells) where ${UnSeT:-~} (and similar)
does not expand the ~ is fixed (note that ${UnSeT:-~/} does expand,
this should give a clue to the cause of the problem.
3. A fix/change to make the effects of ~ expansions on ${UnSeT:=whatever}
identical to those in UnSeT=whatever In particular, with HOME=/foo
${UnSeT:=~:~} now assigns, and expands to, /foo:/foo rather than ~:~
just as VAR=~:~ assigns /foo:/foo to VAR. Note this is even after the
previous fix (ie: appending a '/' would not change the results here.)
It is hard to call this one a bug fix for certain (though I believe it is)
as many other shells also produce different results for the ${V:=...}
expansions than they do for V=... (though not all the same as we did).
POSIX is not clear about this, expanding ~ after : in VAR=whatever
assignments is clear, whether ${U:=whatever} assignments should be
treated the same way is not stated, one way or the other.
4. Change to make ':' terminate the user name in a ~ expansion in all cases,
not only in assignments. This makes sense, as ':' is one character that
cannot occur in user names, no matter how otherwise weird they become.
bash (incl in posix mode) ksh93 and bosh all act this way, whereas most
other shells (and POSIX) do not. Because this is clearly an extension
to POSIX, do this one only when not in posix mode (not set -o posix).
To generate a diff of this commit:
cvs rdiff -u -r1.110.2.2 -r1.110.2.3 src/bin/sh/expand.c
cvs rdiff -u -r1.146.2.3 -r1.146.2.4 src/bin/sh/sh.1
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: snj Date: Wed Oct 25 07:03:10 UTC 2017 Modified Files: src/bin/sh [netbsd-8]: sh.1 Log Message: Pull up following revision(s) (requested by kre in ticket #323): bin/sh/sh.1: revision 1.168 Fix typo: s/one or mode/one or more/ To generate a diff of this commit: cvs rdiff -u -r1.146.2.4 -r1.146.2.5 src/bin/sh/sh.1 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Fri Nov 17 14:56:52 UTC 2017 Modified Files: src/bin/sh [netbsd-8]: jobs.c Log Message: Pull up following revision(s) (requested by kre in ticket #337): bin/sh/jobs.c: revision 1.91 (patch) PR bin/52640 PR bin/52641 Don't delete jobs from the jobs table merely because they finished, if they are not the job we are waiting upon. (bin/52640 part 1) In a sub-shell environment, don't allow wait to find jobs from the parent shell that had already exited (before the sub-shell was created) and return status for them as if they are our children. (bin/52640 part 2) Don't have the "jobs" command also be an implicit "wait" command in non-interactive shells. (bin/52641) Use WCONTINUED (when it exists) so we can report on stopped jobs that "mysteriously" move back to running state without the user issuing a "bg" command (eg: kill -CONT ) Previously they would keep being reported as stopped until they exited. When a job is detected as having changed status just as we're issuing a "jobs" command (i.e.: the change occurred between the last prompt and the jobs command being entered) don't report it twice, once from the status change, and then again in the jobs command output. Once is enough (keep the jobs output, suppress the other). Apply some sanity to the way jobs_invalid is processed - ignore it in getjob() instead of just ignoring it most of the time there, and instead always check it before calling getjob() in situations where we can handle only children of the current shell. This allows the (totally broken) save/clear/restore of jobs_invalid in jobscmd() to be done away with (previously an error while in the clear state would have left jobs_invalid incorrectly cleared - shouldn't have mattered since jobs_invalid => subshell => error causes exit, but better to be safe). Add/improve the DEBUG more tracing. To generate a diff of this commit: cvs rdiff -u -r1.85.2.1 -r1.85.2.2 src/bin/sh/jobs.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: snj Date: Fri Nov 17 20:33:53 UTC 2017 Modified Files: src/bin/sh [netbsd-8]: parser.c Log Message: Pull up following revision(s) (requested by kre in ticket #355): bin/sh/parser.c: revision 1.145 PR bin/52715 Correct a (relatively harmless) use after free in prompt expansion processing [detected by asan.] Relatively harmless: as (while incorrect) the way the data is (was) used more or less guaranteed that the buffer contents would be unaltered until well after they are (were) no longer wanted (this is the expanded prompt string, it is just output (or copied into libedit internal storage) and forgotten. This should make no visible difference to anyone (not using asan or similar.) To generate a diff of this commit: cvs rdiff -u -r1.132.2.2 -r1.132.2.3 src/bin/sh/parser.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src
Committed By: martin
Date: Thu Nov 23 13:26:01 UTC 2017
Modified Files:
src/bin/sh [netbsd-8]: output.c
Log Message:
Pull up following revision(s) (requested by kre in ticket #384):
bin/sh/output.c: revision 1.37
Improve quoting in xtrace (-x) output ... if a string ("word") to be
output includes a single quote (') then see if using double-quotes
to quote it is reasonable (if no chars that are magic in " also appear).
If so, and if the string is not entirely the ' character, then
use " quoting. This avoids some ugly looking results (occasionally).
Also, fix a bug introduced about 20 months ago where null strings
in xtrace output are dropped, instead of made explicit ('').
To observe this, before you get the fix: set -x; echo '' (or similar.)
Move a comment from the wrong place to the right place.
To generate a diff of this commit:
cvs rdiff -u -r1.36 -r1.36.2.1 src/bin/sh/output.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src
Committed By: martin
Date: Sun May 6 09:32:57 UTC 2018
Modified Files:
src/bin/sh [netbsd-8]: parser.c
Log Message:
Pull up following revision(s) (requested by kre in ticket #804):
bin/sh/parser.c: revision 1.146
PR bin/53201
Don't synerr on
${var-anything
more}
The newline in the middle of the var expansion is permitted.
Bug reported by Martijn Dekker from his modernish tests.
XXX pullup-8
To generate a diff of this commit:
cvs rdiff -u -r1.132.2.3 -r1.132.2.4 src/bin/sh/parser.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Mon Dec 7 19:39:09 UTC 2020 Modified Files: src/bin/sh [netbsd-8]: exec.c Log Message: Pull up following revision(s) (requested by kre in ticket #1629): bin/sh/exec.c: revision 1.54 PR bin/55526 Fix a bug that has existed since the "command" command was added in 2003. "command foo" would cause the definition of a function "foo" to be lost (not freed, simply discarded) if "foo" is (in addition to being a function) a filesystem command. The case where "foo" is a builtin was handled. For now, when a function exists with the same name as a filesystem command, the latter can never appear in the command hash table, and when used (which can only be via "command foo", just "foo" finds the function) will always result in a full PATH search. XXX pullup everything (from NetBSD 2.0 onwards). (really -8 and -9) To generate a diff of this commit: cvs rdiff -u -r1.47.2.4 -r1.47.2.5 src/bin/sh/exec.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src
Committed By: snj
Date: Mon Jun 5 08:10:24 UTC 2017
Modified Files:
src/bin/sh [netbsd-8]: cd.c eval.c exec.c exec.h mail.c sh.1
Log Message:
Pull up following revision(s) (requested by kre in ticket #5):
bin/sh/cd.c: revision 1.48
bin/sh/eval.c: revision 1.141
bin/sh/exec.c: revision 1.48
bin/sh/exec.h: revision 1.25
bin/sh/mail.c: revisions 1.17, 1.18
bin/sh/sh.1: revision 1.147
Make cd (really) do cd -P, and not just claim that is what it is doing
while doing a half-hearted, broken, partial, version of cd -L instead.
The latter (as the manual says) is not supported, what's more, it is an
abomination, and should never be supported (anywhere.)
Fix the doc so that the pretense that we notice when a path given crosses
a symlink (and turns on printing of the destination directory) is claimed
no more (that used to be true until late Dec 2016, but was changed). Now
the print happens if -o cdprint is set, or if an entry from CDPATH that is
not "" or "." is used (or if the "cd dest repl" cd cmd variant is used.)
Fix CDPATH processing: avoid the magic '%' processing that is used for
PATH and MAILPATH from corrupting CDPATH. The % magic (both variants)
remains undocumented.
Also, don't double the '/' if an entry in PATH or CDPATH ends in '/'
(as in CDPATH=":/usr/src/"). A "cd usr.bin" used to do
chdir("/usr/src//usr.bin"). No more. This is almost invisible,
and relatively harmless, either way
Also fix a bug where if a plausible destination directory in CDPATH
was located, but the chdir() failed (eg: permission denied) and then
a later "." or "" CDPATH entry succeeded, "print" mode was turned on.
That is:
cd /tmp; mkdir bin
mkdir -p P/bin; chmod 0 P/bin
CDPATH=/tmp/P:
cd bin
would cd to /tmp/bin (correctly) but print it (incorrectly).
Also when in "cd dest replace" mode, if the result of the replacement
generates '-' as the path named, as in:
cd $PWD -
then simply change to '-' (or attempt to, with CDPATH search), rather
than having this being equivalent to "cd -")
Because of these changes, the pwd command (and $PWD) essentially
always acts as pwd -P, even when called as pwd -L (which is still
the default.) That is, even more than it did before.
Also fixed a (kind of minor) mem management error (CDPATH related)
"whosoever shall padvance must stunalloc before repeating" (and the
same for MAILPATH).
--
If we are going to keep the MAILPATH % hack, then at least do something
rational. Since it isn't documented, what "rational" is is up for
discussion, but what it did before was not it (it was nonsense...).
To generate a diff of this commit:
cvs rdiff -u -r1.47 -r1.47.6.1 src/bin/sh/cd.c
cvs rdiff -u -r1.140 -r1.140.2.1 src/bin/sh/eval.c
cvs rdiff -u -r1.47 -r1.47.2.1 src/bin/sh/exec.c
cvs rdiff -u -r1.24 -r1.24.8.1 src/bin/sh/exec.h
cvs rdiff -u -r1.16 -r1.16.90.1 src/bin/sh/mail.c
cvs rdiff -u -r1.146 -r1.146.2.1 src/bin/sh/sh.1
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: snj Date: Mon Jun 5 08:15:16 UTC 2017 Modified Files: src/bin/sh [netbsd-8]: expand.c Log Message: Pull up following revision(s) (requested by kre in ticket #7): bin/sh/expand.c: revisions 1.111, 1.112 PR bin/52272 - fix an off-by one that broke ~ expansions. -- Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one. To generate a diff of this commit: cvs rdiff -u -r1.110 -r1.110.2.1 src/bin/sh/expand.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: snj Date: Fri Jun 9 16:53:39 UTC 2017 Modified Files: src/bin/sh [netbsd-8]: sh.1 Log Message: Pull up following revision(s) (requested by kre in ticket #15): bin/sh/sh.1: revision 1.148 Fix a typo (or rather a remnant of an earlier intent). To generate a diff of this commit: cvs rdiff -u -r1.146.2.1 -r1.146.2.2 src/bin/sh/sh.1 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Fri Jul 13 14:29:15 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: eval.c exec.c exec.h mknodes.sh nodes.c.pat Log Message: Pull up following revision(s) (requested by kre in ticket #906): bin/sh/eval.c: revision 1.155 bin/sh/mknodes.sh: revision 1.3 bin/sh/nodes.c.pat: revision 1.14 bin/sh/exec.h: revision 1.27 bin/sh/exec.c: revision 1.52 Deal with ref after free found by ASAN when a function redefines itself, or some other function which is still active. This was a long known bug (fixed ages ago in the FreeBSD sh) which hadn't been fixed as in practice, the situation that causes the problem simply doesn't arise .. ASAN found it in the sh dotcmd tests which do have this odd "feature" in the way they are written (but where it never caused a problem, as the tests are so simple that no mem is ever allocated between when the old version of the function was deleted, and when it finished executing, so its code all remained intact, despite having been freed.) The fix is taken from the FreeBSD sh. XXX -- pullup-8 (after a while to ensure no other problems arise). To generate a diff of this commit: cvs rdiff -u -r1.140.2.2 -r1.140.2.3 src/bin/sh/eval.c cvs rdiff -u -r1.47.2.2 -r1.47.2.3 src/bin/sh/exec.c cvs rdiff -u -r1.24.8.2 -r1.24.8.3 src/bin/sh/exec.h cvs rdiff -u -r1.2 -r1.2.56.1 src/bin/sh/mknodes.sh cvs rdiff -u -r1.13 -r1.13.26.1 src/bin/sh/nodes.c.pat Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Fri Jul 13 14:32:01 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: expand.c Log Message: Pull up following revision(s) (requested by kre in ticket #907): bin/sh/expand.c: revision 1.122 When matching a char class ([[:name:]]) in a pattern (for filename expansion, case patterrns, etc) do not force '[' to be a member of every class. Before this fix, try: case [ in [[:alpha:]]) echo Huh\?;; esac XXX pullup-8(Perhaps -7 as well, though that shell version has much more relevant bugs than this one.) This bug is not in -6 as that has no charclass support. To generate a diff of this commit: cvs rdiff -u -r1.110.2.3 -r1.110.2.4 src/bin/sh/expand.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Sat Aug 25 11:45:40 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: eval.c Log Message: Pull up following revision(s) (requested by kre in ticket #982): bin/sh/eval.c: revision 1.157 PR bin/42184 PR bin/52687 (detailing the same bug). Fix "command not found" handling so that the error message goes to stderr (after any redirections are applied). More importantly, in foo > /tmp/junk /tmp/junk should be created, before any attempt is made to execute (the assumed non-existing) "foo". All this was always true for any command (not found command) containing a / in its name foo/bar >/tmp/junk 2>>/tmp/errs would have created /tmp/junk, then complained (in /tmp/errs) about foo/bar not being found. Now that happens for ordinary commands as well. The fix (which I found when I saw differences between our code and FreeBSD's, where, for the benefit of PR 42184, this has been fixed, sometime in the past 9 years) is frighteningly simple. Simply do not short circuit execution (or print any error) when the initial lookup fails to find the command - it will fail anyway when we actually try running it. The cost is a (seemingly unnecessary, except that it really is) fork in this case. This is what I had been planning, but I expected it would be much more difficult than it turned out XXX pullup-8 To generate a diff of this commit: cvs rdiff -u -r1.140.2.3 -r1.140.2.4 src/bin/sh/eval.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Sat Aug 25 14:22:50 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: eval.c eval.h main.c Log Message: Pull up following revision(s) (requested by kre in ticket #983): bin/sh/eval.c: revision 1.158 bin/sh/eval.h: revision 1.21 bin/sh/main.c: revision 1.74 PR bin/48875 Revert the changes that were made 19 May 2016 (principally eval.c 1.125) and the bug fixes in subsequent days (eval.c 1.126 and 1.127) and also update some newer code that was added more recently which acted in accordance with those changes (make that code be as it would have been if the changes now being reverted had never been made). While the changes made did solve the problem, in a sense, they were never correct (see the PR for some discussion) and it had always been intended that they be reverted. However, in practical sh code, no issues were reported - until just recently - so nothing was done, until now... After this commit, the validate_fn_redirects test case of the sh ATF test t_redir will fail. In particular, the subtest of that test case which is described in the source (of the test) as: This one is the real test for PR bin/48875 will fail. Alternative changes, not to "fix" the problem in the PR, but to often avoid it will be coming very soon - after which that ATF test will succeed again. XXX pullup-8 To generate a diff of this commit: cvs rdiff -u -r1.140.2.4 -r1.140.2.5 src/bin/sh/eval.c cvs rdiff -u -r1.19 -r1.19.8.1 src/bin/sh/eval.h cvs rdiff -u -r1.70.2.1 -r1.70.2.2 src/bin/sh/main.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Sat Aug 25 14:41:22 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: trap.c Log Message: Pull up following revision(s) (requested by kre in ticket #987): bin/sh/trap.c: revision 1.44 PR bin/36532 (perhaps) This is more or less the same patch as provided in the PR (just 11 years later, so changed a bit) by woods@... Since there is no known way to actually cause the reported crash, we may never know if this change actually fixes anything. But even if it doesn't it certainly cannot hurt. There is a potential race which could possibly explain the issue (see commentary in the PR) which is not easy to avoid - if that is the actual cause, this should provide a defence, if not really a fix. To generate a diff of this commit: cvs rdiff -u -r1.40.2.1 -r1.40.2.2 src/bin/sh/trap.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Sat Aug 25 14:45:37 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: histedit.c mystring.c options.c parser.c var.c Log Message: Pull up following revision(s) (requested by kre in ticket #988): bin/sh/parser.c: revision 1.147 bin/sh/var.c: revision 1.70 bin/sh/mystring.c: revision 1.18 bin/sh/options.c: revision 1.53 bin/sh/histedit.c: revision 1.53 Remove atoi() Mostly use number() (no longer implemented using atoi()) when an unsigned integer is required, but use strtoXXX() when a conversion is wanted, without the possibility or error (like setting OPTIND and RANDOM). Always init OPTIND to 1 when sh starts (overriding anything in environ.) To generate a diff of this commit: cvs rdiff -u -r1.48.8.1 -r1.48.8.2 src/bin/sh/histedit.c cvs rdiff -u -r1.17 -r1.17.22.1 src/bin/sh/mystring.c cvs rdiff -u -r1.49 -r1.49.2.1 src/bin/sh/options.c cvs rdiff -u -r1.132.2.4 -r1.132.2.5 src/bin/sh/parser.c cvs rdiff -u -r1.55.2.2 -r1.55.2.3 src/bin/sh/var.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Sat Aug 25 14:48:22 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: eval.c eval.h exec.c Log Message: Pull up following revision(s) (requested by kre in ticket #989): bin/sh/eval.c: revision 1.156 bin/sh/eval.h: revision 1.20 bin/sh/exec.c: revision 1.53 Fix several bugs in the command / type builtin ( including PR bin/48499 ) 1. Make command -pv (and -pV) work (which is not as easy as the PR suggests it might be (the "check and cause error" was there because it did not work, not in order to prevent it from working). 2. Stop -v and -V being both used (that makes no sense). 3. Stop the "type" builtin inheriting the args (-pvV) that "command" has (which it did, as when -v -or -V is used with command, it and type are implemented using the same code). 4. make "command -v word" DTRT for sh keywords (was treating them as an error). 5. Require at least one arg for "command -[vV]" or "type" else usage & error. Strictly this should also apply to "command" and "command -p" (no -v) but that's handled elsewhere, so perhaps some other time. Perhaps "command -v" (and -V) should be limited to 1 command name (where "type" can have many) as in the POSIX definitions, but I don't think that matters. 6. With "command -V alias", (or "type alias" which is the same thing), (but not "command -v alias") alter the output format, so we get ll is an alias for: ls -al instead of the old ll is an alias for ls -al (and note there was a space, for some reason, after "for") That is, unless the alias value contains any \n characters, in which case (something approximating) the old multi-line format is retained. Also note: that if code wants to parse/use the value of an alias, it should be using the output of "alias name", not command or type. Note that none of the above affects "command [-p] cmd" (no -v or -V options) only "command -[vV]" and "type". Note also that the changes to eval.[ch] are merely to make syspath() visible in exec.c rather than static in eval.c To generate a diff of this commit: cvs rdiff -u -r1.140.2.5 -r1.140.2.6 src/bin/sh/eval.c cvs rdiff -u -r1.19.8.1 -r1.19.8.2 src/bin/sh/eval.h cvs rdiff -u -r1.47.2.3 -r1.47.2.4 src/bin/sh/exec.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Sat Aug 25 17:14:39 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: eval.c Log Message: Fix merge mishap due to #983 / #989 pullup order. To generate a diff of this commit: cvs rdiff -u -r1.140.2.6 -r1.140.2.7 src/bin/sh/eval.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Mon Sep 10 15:45:11 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: expand.c parser.c syntax.c syntax.h Log Message: Pull up following revision(s) via patch (requested by kre in ticket #1015): bin/sh/expand.c: revision 1.124 bin/sh/expand.c: revision 1.127 bin/sh/parser.c: revision 1.148 bin/sh/parser.c: revision 1.149 bin/sh/syntax.c: revision 1.6 bin/sh/syntax.h: revision 1.9 (partial) First pass at fixing some of the more arcane pattern matching possibilities that we do not currently handle all that well. This mostly means (for now) making sure that quoted pattern magic characters (as well as quoted sh syntax magic chars) are properly marked, so they remain known as being quoted, and do not turn into pattern magic. Also, make sure that an unquoted \ in a pattern always quotes whatever comes next (which, unlike in regular expressions, includes inside [] matches), - Part 2 of pattern matching (glob etc) fixes. Attempt to correctly deal with \ (both when it is a literal, in appropriate cases, and when it appears as CTLESC when it was detected as a quoting character during parsing). In a pattern, in sh, no quoted character can ever be anything other than a literal character. This is quite different than regular expressions, and even different than other uses of glob matching, where shell quoting is not an issue. In something like ls ?\*.c the ? is a meta-character, the * is a literal (it was quoted). This is nothing new, sh has handled that properly for ever. But the same happens with VAR='?\*.c' and ls $VAR which has not always been handled correctly. Of course, in ls "$VAR" nothing in VAR is a meta-character (the entire expansion is quoted) so even the '\' must match literally (or more accurately, no matching happens - VAR simply contains an "unusual" filename). But if it had been ls *"$VAR" then we would be looking for filenames that end with the literal 5 characters that make up $VAR. The same kinds of things are requires of matching patterns in case statements, and sub-strings with the % and # operators in variable expansions. While here, the final remnant of the ancient !! pattern matching hack has been removed (the code that actually implemented it was long gone, but one small piece remained, not doing any real harm, but potentially wasting time - if someone gave a pattern which would once have invoked that hack.) To generate a diff of this commit: cvs rdiff -u -r1.110.2.4 -r1.110.2.5 src/bin/sh/expand.c cvs rdiff -u -r1.132.2.5 -r1.132.2.6 src/bin/sh/parser.c cvs rdiff -u -r1.3.26.1 -r1.3.26.2 src/bin/sh/syntax.c cvs rdiff -u -r1.7.2.1 -r1.7.2.2 src/bin/sh/syntax.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Tue Oct 9 09:51:57 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: jobs.c Log Message: Pull up following revision(s) (requested by kre in ticket #1050): bin/sh/jobs.c: revision 1.101 A change in rev 1.91 interacted badly with the way that showjobs() worked, preventing $(jobs) (and more usefully $(jobs -p) from working. Fix that. XXX pullup -8 To generate a diff of this commit: cvs rdiff -u -r1.85.2.2 -r1.85.2.3 src/bin/sh/jobs.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Sun Oct 21 12:00:33 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: mkinit.sh Log Message: Pull up following revision(s) (requested by kre in ticket #1067): bin/sh/mkinit.sh: revision 1.9 Dynamically detect the way the shell matches \ in a pattern, and use whatever works for the sh running this script. Previously we were using the (broken, and incorrect) method that worked in old broken NetBSD sh's (and some others) and not the method that works with the current (fixed) /bin/sh and other correct shells (like bash). (For an exotic reason, in the particular use case, both methods work with ksh93, but it is also generally correct). This hasn't really mattered, as the difference is only significant (only causes actual issues - the build fails) when compiling with DEBUG enabled, which is something that most sane humans would never do, if they want to retain that sanity. The problem was detected by Patrick Welche when looking for an unrelated problem, which was once considered to be a possible sh problem, but turned out to be something entirely different. XXX pullup -8 To generate a diff of this commit: cvs rdiff -u -r1.7 -r1.7.8.1 src/bin/sh/mkinit.sh Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Mon Nov 12 08:46:54 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: parser.c Log Message: Pull up following revision(s) (requested by kre in ticket #1086): bin/sh/parser.c: revision 1.152 PR bin/53712 Avoid crash from redirect on null compound command. To generate a diff of this commit: cvs rdiff -u -r1.132.2.6 -r1.132.2.7 src/bin/sh/parser.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Fri Dec 7 13:12:02 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: redir.c Log Message: Pull up following revision(s) (requested by kre in ticket #1125): bin/sh/redir.c: revision 1.61 Fix the <> redirection operator, which has been broken since it was first implemented in response to PR bin/4966 (PR Feb 1998, fix Feb 1999). The file named should not be truncated. No other shell truncates the file (<> was added to FreeBSD sh in Oct 2000, and did not include O_TRUNC) and POSIX certainly does not suggest that should happen (just that the file is to be created if it does not exist.) Bug pointed out in off-list e-mail by Martijn Dekker To generate a diff of this commit: cvs rdiff -u -r1.57.2.1 -r1.57.2.2 src/bin/sh/redir.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Fri Dec 7 13:14:42 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: alias.c Log Message: Pull up following revision(s) (requested by kre in ticket #1126): bin/sh/alias.c: revision 1.19 Fix the worst of the bugs in alias processing. This has been in sh since this code was first imported (May 1994) (ie: before 4.4-Lite) There is (much) more coming soon (the big ugly comment is going away). This one has been separated out, as it can easily cause sh core dumps, so needs: XXX pullup-8 (the other changes to aliases probably will not get that.) To generate a diff of this commit: cvs rdiff -u -r1.15 -r1.15.16.1 src/bin/sh/alias.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: [netbsd-8] src/bin/sh
Module Name:src Committed By: martin Date: Fri Dec 7 13:23:49 UTC 2018 Modified Files: src/bin/sh [netbsd-8]: sh.1 var.c var.h Log Message: Pull up following revision(s) (requested by kre in ticket #1127): bin/sh/var.h: revision 1.38 (via patch) bin/sh/var.c: revision 1.72 bin/sh/sh.1: revision 1.211 (via patch) Alter a design botch when magic (self modifying) variables were added to sh ... in other shells, setting such a variable (for most of them) causes it to lose its special properties, and act the same as any other variable. I had assumed that was just implementor laziness... I was wrong. >From now on the NetBSD shell will act like the others, and if vars like HOSTNAME (and SECONDS, etc) are used as variables in a script or whatever, they will act just like normal variables (and unless this happens when they have been made local, or as a variable-assignment as a prefix to a command, the special properties they would have had otherwise are lost for the remainder of the life of the (sub-)shell in which the variables were set). Importing a value from the environment counts as setting the value for this purpose (so if HOSTNAME is set in the environment, the value there will be the value $HOSTNAME expands to). The two exceptions to this are LINENO and RANDOM. RANDOM needs to be able to be set to (re-)set its seed. LINENO needs to be able to be set (at least in the "local" command) to achieve the desired functionality. It is unlikely that any (sane) script is going to want to use those two as normal vars however. While here, fix a minor bug in popping local vars (fn return) that need to notify the shell of changes in value (like PATH). Change sh(1) to reflect this alteration. Also add doc of the (forgotten) magic var EUSER (which has been there since the others were added), and add a few more vars (which are documented in other places in sh(1) - like ENV) into the defined or used variable list (as well as wherever else they appear). XXX pullup -8 To generate a diff of this commit: cvs rdiff -u -r1.146.2.5 -r1.146.2.6 src/bin/sh/sh.1 cvs rdiff -u -r1.55.2.3 -r1.55.2.4 src/bin/sh/var.c cvs rdiff -u -r1.28.8.1 -r1.28.8.2 src/bin/sh/var.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
