sh/tests: Add a second kind of binary scripts without #!One of the reasons for git commite0f5c1387df23c8c4811f5b24a7ef6ecac51a71a was to make "actually portableexecutables" work. Add a test that
sh/tests: Add a second kind of binary scripts without #!One of the reasons for git commite0f5c1387df23c8c4811f5b24a7ef6ecac51a71a was to make "actually portableexecutables" work. Add a test that is more like those.MFC after: 1 week
show more ...
sh: Write absolute path in command -vV and typePOSIX is pretty clear that command -v, command -V and type shall writeabsolute pathnames. Therefore, we need to prepend the current directory'sname
sh: Write absolute path in command -vV and typePOSIX is pretty clear that command -v, command -V and type shall writeabsolute pathnames. Therefore, we need to prepend the current directory'sname to relative pathnames.This can happen either when PATH contains a relative pathname or when theoperand contains a slash but is not an absolute pathname.
sh: Keep ignored SIGINT/SIGQUIT after set in a background jobIf job control is not enabled, a background job (... &) ignores SIGINT andSIGQUIT, but this can be reverted using the trap builtin in t
sh: Keep ignored SIGINT/SIGQUIT after set in a background jobIf job control is not enabled, a background job (... &) ignores SIGINT andSIGQUIT, but this can be reverted using the trap builtin in the same shellenvironment.Using the set builtin to change options would also revert SIGINT and SIGQUITto their previous dispositions.This broke due to r317298. Calling setsignal() reverts the effect ofignoresig().Reported by: bdreweryMFC after: 1 week
sh/tests: Re-enable bin.sh.execution.functional_test.bg12.0This reverts r362646.PR: 247559MFC after: 1 week
sh/tests: Fix flaky execution/bg12.0When job control is not enabled, the shell ignores SIGINT while waiting fora foreground process unless that process exits on SIGINT. In this case, theforegroun
sh/tests: Fix flaky execution/bg12.0When job control is not enabled, the shell ignores SIGINT while waiting fora foreground process unless that process exits on SIGINT. In this case, theforeground process is sleep and it does not exit on SIGINT because thesignal is only sent to the shell. Depending on order of events, this couldcause the SIGINT to be unexpectedly ignored.On lightly loaded bare metal, the chance of this happening tends to be lessthan 0.01% but with higher loads and/or virtualization it becomes morelikely.Starting the sleep in background and using the wait builtin ensures SIGINTwill not be ignored.PR: 247559Reported by: lwhsuMFC after: 1 week
Temporarily skip flakey bin.sh.execution.functional_test.bg12 in CIPR: 238870Sponsored by: The FreeBSD Foundation
sh/tests: Add tests for SIGINT in non-jobc background commandsIf job control is not enabled, background commands shall ignore SIGINT andSIGQUIT, and it shall be possible to override that ignore in
sh/tests: Add tests for SIGINT in non-jobc background commandsIf job control is not enabled, background commands shall ignore SIGINT andSIGQUIT, and it shall be possible to override that ignore in the same shell.MFC after: 1 week
sh: Allow more scripts without #!Austin Group bugs #1226 and #1250 changed the requirements for shell scriptswithout #! (POSIX does not specify #!; this is about the shell executionwhen execve(2)
sh: Allow more scripts without #!Austin Group bugs #1226 and #1250 changed the requirements for shell scriptswithout #! (POSIX does not specify #!; this is about the shell executionwhen execve(2) returns an [ENOEXEC] error).POSIX says we shall allow execution if the initial part intended to beparsed by the shell consists of characters and does not contain the NULcharacter. This allows concatenating a shell script (ending with exec orexit) and a binary payload.In order to reject common binary files such as PNG images, check that thereis a lowercase letter or expansion before the last newline before the NULcharacter, in addition to the check for the newline character suggested byPOSIX.
sh: Fix double INTON with vforkThe shell maintains a count of the number of times SIGINT processing hasbeen disabled via INTOFF, so SIGINT processing resumes when all disableshave enabled again (
sh: Fix double INTON with vforkThe shell maintains a count of the number of times SIGINT processing hasbeen disabled via INTOFF, so SIGINT processing resumes when all disableshave enabled again (INTON).If an error occurs in a vfork() child, the processing of the error enablesSIGINT processing again, and the INTON in vforkexecshell() causes the countto become negative.As a result, a later INTOFF may not actually disable SIGINT processing. Thismight cause memory corruption if a SIGINT arrives at an inopportune time. Asof r360452, it causes the shell to abort when it would unsafely allocate orfree memory in certain ways.Note that various places such as errors in non-special builtinsunconditionally reset the count to 0, so the problem might still not alwaysbe visible.PR: 246497Reported by: jbeichMFC after: 2 weeks
sh/tests: Test some obscure cases with aliasing keywords
sh: Test that executing various binary files is rejectedIf executing a file fails with an [ENOEXEC] error, the shell executes thefile as a shell script, except that this execution may instead resu
sh: Test that executing various binary files is rejectedIf executing a file fails with an [ENOEXEC] error, the shell executes thefile as a shell script, except that this execution may instead result in anerror message if the file is binary.Per a recent Austin Group interpretation, we will need to change this toallow a concatenation of a shell script and a binary payload. SeeAustin Group bugs #1226 and #1250.MFC after: 1 week
sh/tests: Improve failure messages of expansion/arith15.0
sh: Add set -o pipefailThe pipefail option allows checking the exit status of all commands in apipeline more easily, at a limited cost of complexity in sh itself. It workssimilarly to the option
sh: Add set -o pipefailThe pipefail option allows checking the exit status of all commands in apipeline more easily, at a limited cost of complexity in sh itself. It workssimilarly to the option in bash, ksh93 and mksh.Like ksh93 and unlike bash and mksh, the state of the option is saved when apipeline is started. Therefore, even in the case of commands like A | B &a later change of the option does not change the exit status, the same way (A | B) &works.Since SIGPIPE is not handled specially, more work in the script is requiredfor a proper exit status for pipelines containing commands such as head thatmay terminate successfully without reading all input. This can be somethinglike( cmd1 r=$? if [ "$r" -gt 128 ] && [ "$(kill -l "$r")" = PIPE ]; then exit 0 else exit "$r" fi) | headPR: 224270Relnotes: yes
sh: Restore $((x)) error checking after fix for $((-9223372036854775808))SVN r342880 was designed to fix $((-9223372036854775808)) and things like$((0x8000000000000000)) but also broke error detec
sh: Restore $((x)) error checking after fix for $((-9223372036854775808))SVN r342880 was designed to fix $((-9223372036854775808)) and things like$((0x8000000000000000)) but also broke error detection for values ofvariables without dollar sign ($((x))).For compatibility, overflow in plain literals continues to be ignored andthe value is clamped to the boundary (except 9223372036854775808 which ischanged to -9223372036854775808).Reviewed by: se (although he would like error checking to be removed)MFC after: 2 weeksX-MFC-with: r342880Differential Revision: https://reviews.freebsd.org/D18926
Fix an edge case when parsing large numbers which resulted in inconsistentresults between an expression that refers to a variable by name and thesame expression that includes the same variable by v
Fix an edge case when parsing large numbers which resulted in inconsistentresults between an expression that refers to a variable by name and thesame expression that includes the same variable by value.Submitted by: se@MFC after: 1 week
sh: Add test for exported but unset variablesPR: 233545
sh: Fix ${param?} default error messageIf word in ${param?word} is missing, the shell shall write a default errormessage. So expanding ${param?} when param is not set should write an errormessage
sh: Fix ${param?} default error messageIf word in ${param?word} is missing, the shell shall write a default errormessage. So expanding ${param?} when param is not set should write an errormessage likesh: param: parameter not setThis was broken by r316417.PR: 233585
sh: Use 126 and 127 exit status for failures opening a scriptThis affects scripts named on the command line, named with a '.' specialbuiltin and found via the PATH %func autoloading mechanism.PR
sh: Use 126 and 127 exit status for failures opening a scriptThis affects scripts named on the command line, named with a '.' specialbuiltin and found via the PATH %func autoloading mechanism.PR: 231986
sh: Don't treat % specially in CDPATH
sh: Allow unquoted newlines in word in ${param+word} etc.POSIX requires accepting unquoted newlines in word in parameter expansionslike ${param+word}, ${param#word}, although the Bourne shell did
sh: Allow unquoted newlines in word in ${param+word} etc.POSIX requires accepting unquoted newlines in word in parameter expansionslike ${param+word}, ${param#word}, although the Bourne shell did not supportit, it is not commonly used and might make it harder to find a missingclosing brace.It was also strange that something likefoo="${bar#}"was rejected.Reported by: Martijn Dekker via Robert Elz
sh: Test that backslash-newline within single-quotes is not specialThis works correctly, but the test may be helpful when modifying the parser.
sh: Don't have [ match any [[:class:]]Submitted by: Robert ElzMFC after: 3 days
Fix a few speelling errors- man pages- bin/shReviewed by: jilles
DIRDEPS_BUILD: Connect new directories.Sponsored by: Dell EMC Isilon
sh: Add test for sh -c with missing command string.This already works correctly.
12345