summaryrefslogtreecommitdiff
path: root/bin/sh
AgeCommit message (Collapse)Author
2023-06-24Fix typo in a debug message.msaitoh
2023-04-07Remove an end of file trailing blank line that served no purpose.kre
NFCI
2023-04-07The great shell trailing whitespace cleanup of 2023...kre
Inspired by private e-mail comments from mouse@ NFCI.
2023-03-21Use "sigjmp_buf loc" after switch to sigsetjmp()/siglongjmp().hannken
Fixes errors and aborts on sparc at least.
2023-03-19Do a better job handling EACCES errors from exec() calls. If thekre
EACCES is from the namei(), treat it just like ENOENT or ENOTDIR (and if that is the final error, the exit status from a failed exec will be 127). If the EACCES is from the exec() itself, that indicates the file to be run exists, but has no 'x' permission. That's a meaningful error (as distinct from just "yet another PATH element search failure"). While here, return the first meaingful error we encountered while searching PATH, rather than the last (and ENOENT if there are none of those). This change results in some failed command executions returning status 127 now, where they returned 126 before - which better reflects the intent of those values (127 is simply "not found" whereas 126 is "found but couldn't be executed"). We still do nothing to distinguish errors encountered looking up the command name give, with errors encountered (by the kernel) attempting to run an interpreter needed for the exec to succeed (#! line path, or /libexec/ld.elf_so and similar - or anything else of a similar nature).
2023-03-19Switch from using _setjmp()/_longjmp() (on BSD systems which aren't SVR4)kre
(and setjmp()/longjmp() elsewhere) to using sigsetjmp()/siglongjmp() everywhere. NFCI.
2023-03-19Change a few #defines from octal to hex (pdp11 days are long gone).kre
Improve the layout of those definitions at the same time. NFC.
2023-03-06Adjust tilde expansion as will be documented in the forthcomingkre
version of the POSIX standard (Issue 8). I believe we were already compliant with what is to be required, but POSIX is now encouraging (and will likely require in a later version) that if a tilde expansion produces a string which ends in a '/' and the '~' that was expanded is immediately followed by a '/' in the input word, that one of those two slashes be omitted. The worst (current) example of this is when HOME=/ and we expand ~/foo - previously producing //foo which is (in POSIX) a path with implementation defined semantics, and so not what we should be generating by accident. Change that, so now if the ~ prefix expansion ends in a '/' and there is a '/' following immediately after, the resulting word contains only one of those chars (in the example just given, we will now produce /foo instead). POSIX is also making it clear that the expansion that results from the tilde expansion is treated as quoted (not subject to pathname expansion, or field splitting, or any var/arith/command substitutions) and that if HOME="" the expansion of ~ must generate "" (not nothing). Our implementation did all of that already (though older versions used to treat an empty expansion of HOME the same as if HOME was unset - that was fixed some time ago). The actual modification made here is probably smaller than this log entry, and without added comments, certainly is!
2023-02-24Allow (but do not require) the magic '--' option terminator inkre
the builtin 'alias' command. This allows portability (not that anyone should really care with aliases) for scripts from other shells in which the alias command has options, and the -- is required to allow the first alias name to begin with a '-'. That is, for us, alias -x='echo x' works fine, always has, and still does. But other shells treat that as an attempt to use the -x option (and maybe -= etc), and require alias -- -x='echo x'. For us that variant used to complain about the alias -- not existing (as an arg with no '=' is treated as a request to extract the value of the alias). Posix also generally requires all standard commands (or which "alias" is one, unfortunately) to support '--' even if they have no options, for precisely this reason.
2022-12-20More markup errors. \+ was intended to be \&+ and .EV .Ev of course.kre
As best I can tell, the rest of what mandoc -Wall complains about is incorrect (it could probably be avoided by adding more markup, but there doesn't seem to be any point).
2022-12-20Using .Cm Cm makes no sense at all - no idea what I was thinking therekre
(perhaps just an editing error).
2022-12-20sh(1): Fix markup. -compact must be last.uwe
2022-12-11It appears that POSIX intends to add a -d X option to the read commandkre
in its next version, so it can be used as -d '' (to specify a \0 end character for the record read, rather than the default \n) to accompany find -print0 and xargs -0 options (also likely to be added). Add support for -d now. While here fix a bug where escaped nul chars (\ \0) in non-raw mode were not being dropped, as they are when not escaped (if not dropped, they're still not used in any useful way, they just ended the value at that point).
2022-10-30PR bin/57053 is related (peripherally) here.kre
sh has been remembering the process group of a job for a while now, but using that for almost nothing. The old way to resume a job, was to try each pid in the job with a SIGCONT (using it as the process group identifier via killpg()) until one worked (or none did, in which case resuming would be impossible, but that never actually happened). This wasn't as bad as it seems, as in practice the first process attempted was *always* the correct one. Why the loop was considered necessary I am not sure. Nothing but the first could possibly work. This worked until a fix for an obscure possible bug was added a while ago - now a process which has already finished, and had its zombie collected via wait*() is no longer ever considered to have a pid which is a candidate for use in any system call. That's because the kernel might have reassigned that pid for some newly created process (we have no idea how much time might have passed since the pid was returned to the kernel for reuse, it might have happened weeks ago). This is where the example in bin/57053 revealed a problem. That PR is really about a quite different problem in zsh (from pksrc) and should be pkg/57053, but as the test case also hit the problem here, it was assumed (by some) they were the same issue. The example is (in a small directory) ls | less which is then suspended (^Z), and resumed (fg). Since the directory is small, ls will be finished, and reaped by sh - so the code would now refuse to use its pid for the killpg() call to send the SIGCONT. The (useless) loop would attempt to use less's pid for this purpose (it is still alive at this point) but that would fail, as that pid is not a process group identifier, of anything. Hence the job could not be resumed. Before the PR (or preceding mailing list discussion) the change here had already been made (part of a much bigger set of changes, some of which might follow - sometime). We now actually use the job's remembered process group identifier when we want the process group identifier, instead of trying to guess which pid it happens to be (which actually never took any guessing, it was, and is always the pid of the first process created for the job). A couple of minor fixes to how the pgrp is obtained, and used, accompany the changes to use it when appropriate.
2022-10-30Note in the description of "jobs -p" that the process id returned iskre
also the process group identifier (that's a requirement from POSIX, and is what we have always done - just not been explicit about in sh.1). Add a note that this value and $! are not necessarily the same (currently, and perhaps forever, never the same in a pipeline with 2 or more elements).
2022-09-18Oops, somehow managed to commit an older version where NBSH_INVOCATIONkre
start char was '@' rather than '!' (which meant not lexically ordered). This is how it was intended to be (and is documented).
2022-09-18Add the -l option (aka -o login): be a login shell. Meaningful only onkre
the command line (with both - and + forms) - overrides the presence (or otherwise) of a '-' as argv[0][0]. Since this allows any shell to be a login shell (which simply means that it runs /etc/profile and ~/.profile at shell startup - there are no other side effects) add a new, always set at startup, variable NBSH_INVOCATION which has a char string as its value, where each char has a meaning, more or less related to how the shell was started. See sh(1). This is intended to allow those startup scripts to tailor their behaviour to the nature of this particular login shell (it is possible to detect whether a shell is a login shell merely because of -l, or whether it would have been anyway, before the -l option was added - and more). The var could also be used to set different values for $ENV for different uses of the shell.
2022-09-16More wording improvements. There might be more to come.kre
2022-09-16Minor wording improvements.kre
Note these do not alter anything about what the man page specifies, just say a couple of things in a slightly better way, hence no Dd update accompanies this change (deliberately).
2022-09-16Move a comment that used to be in the correct place, once upon a time,kre
back where it belongs, and make it stand out more, so other text is less likely to find itself pushed between the comment and the text to which it appears. This change should make no visible difference to the man page displayed.
2022-09-16Whitespace.kre
2022-09-15Correct spelling of terminal (it doesn't have a 2nd m).kre
2022-08-22Add debugging trace points for history and the editline interface.kre
NFC for any normal shell (not compiled with debugging (sh DEBUG) enabled. We have had a defined debug mode for this for years, but since I have not often played in this arena, never used it. Until recently (relatively). This (or a small part of it) played a part in discovering the fc -e bug cause. I have had it in my tree a while now - recent changes kept causing merge conflicts (all because I hadn't bothered to commit this), so I think now is the time...
2022-08-21sh(1): revert previous because it interferes with custom user bindingsnia
2022-08-19Improve the description of the read builtin command.kre
2022-08-19Don't output the error for bad usage (no var name given)kre
after already writing the prompt (set with the -p option). That results in nonsense like: $ read -p foo fooread: arg count While here, improve the error message so it means something. Now we will get: $ read -p foo read: variable name required Usage: read [-r] [-p prompt] var... [Detected by code reading while doing the work for the previous fix]
2022-08-19PR bin/56972 Fix escape ('\') handling in sh read builtin.kre
In 1.35 (March 2005) (the big read fixup), most escape handling and IFS processing in the read builtin was corrected. However 2 cases were missed, one is a word (something to be assigned to any variable but the last) in which every character is escaped (the code was relying on a non-escaped char to set the "in a word" status), and second trailing IFS whitespace at the end of the line was being deleted, even if the chars had been escaped (the escape chars are no longer present). See the PR for more details (including the case that detected the problem). After fixing this, I looked at the FreeBSD code (normally might do it before, but these fixes were trivial) to check their implementation. Their code does similar things to ours now does, but in a completely different way, their read builtin is more complex than ours needs to be (they handle more options). For anyone tempted to simply incorporate their code, note that it relies upon infrastructure changes elsewhere in the shell, so would not be a simple cut and drop in exercise. This needs pullups to -3 -4 -5 -6 -7 -8 and -9 (fortunately this is happening before -10 is branched, so will never be broken this way there).
2022-08-18sh(1): Allow an explicit set -o vi or set -o emacs to override ~/.editrcnia
2022-08-17sh(1): Assign the tab completion key binding last so a user havingnia
"bind -v" or "bind -e" in ~/.editrc doesn't cause tab completion to no longer function.
2022-05-31fix various typos in comments, documentation and messages.andvar
2022-04-18Introduce a new macro JNUM to replace the idiom jp-jobtab+1kre
(the job number, given jp a pointer to a jobs table entry) used open coded previously in many places (mostly in DEBUG mode trace messages, so not included in most shells, but there are a few others). Make the type of JNUM() be int rather than the ptrdiff_t the open coded version became ... which when used in some printf() type function arg list was cast to some other arbitrary (but not consistent) int type for which there is a standard %Xd type format conversion. Now we can (and do) just use %d for this. If the number of jobs ever exceeds the range of an int, we would have far more serious problems than the broken output this would cause. While here improve a comment or two, and use JOBRUNNING instead of 0 where the intent is the former (JOBRUNNING is #defined as 0). NFCI.
2022-04-17fix various typos in comments.andvar
2022-04-16Redo the way the builtin cmd 'ulimit' getopt() (nextopt() really, but itkre
is essentially the same) arg string is generated, to lessen the chances that the table of limits, and the arg string that allows limits to be reported or set will get out of sync. They weren't (as long as we didn't grow an RLIMIT_SWAP) this is just tidier. While here, reorder the limits table fields, and shrink a couple that were needlessly wasteful, to save some space -- for most architectures this should save 8 bytes per table entry (there are currently 13). (Some minor code bloat offsets this slightly because of int type promotions now required). NFCI.
2022-04-16While doing the previous change, I noticed that when used in akre
particularly perverse way, the error message for a bad octal constant as the new umask value could incorrectly claim that the -S option (which would need to be present to cause this issue) was the detected bad value. Fix that to report the actual incorrect arg. And while fiddling, also check for args to umask that are too big to be sane mask values (the biggest permitted is 07777) and use mode_t as the mask variable type, rather than int.
2022-04-16Avoid generating error messages implying that user errors are illegal.kre
2022-04-10fix various typos in comments and output/log messages.andvar
2022-02-08sh: fix typo in commentrillig
2022-02-02After (a few days short of) 21 years, revert 1.25, which did nothing exceptkre
make the -e option to "fc" fail to work (the commit message was about some other changes entirely, so I an only assume this was committed by mistake). It says a lot about the use of the fc command that no-one noticed that this did not work properly for all this time. Internally in sh, it is possible for built in commands to use either getopt(3) (from libc) or the much simpler internal shell nextopt() routine for option (flag) parsing. However it makes no sense to use getopt() and then access a global variable set only by nextopt() instead of the one getopt() sets (which is what the code had used previously, forever). Use the correct variable again. XXX pullup -9 -8 (-7 -6 -5 ...)
2022-01-31When we initialize libedit (editline) always call ourselves "sh" nokre
matter what $0 is (or is not) set to. This means that editrc(5) lines that start "sh:" are used (in addition to those with no prefix, which will usually be most of them), regardless of the name or manner in which we were invoked. OK christos@
2022-01-31Add some comments explaining accesses to the environment viakre
getenv()/setenv()/unsetenv() which manipulate the envornoment the shell was passed at entry. These are a little odd in sh as that environment is copied into the shell's internal variable data struct at shell startup, and normally never accessed after that - in builtin commands (test. printf, ...) getenv() is #defined to become an internal sh lookup function instead, so even those never use the startup environment). NFCI
2022-01-22After 3 and a bit years, it is time...kre
2022-01-07sh(1): improve getopts docs for optstring leading :lukem
getopts has different behaviour if the leading character of optstring is `:', so describe in more detail: - no errors are printed (already there) - unknown options set var to `?' and OPTARG to the unknown option - missing arguments set var to `:' and OPTARG to the option name Slight rewording of other paragraphs for more clarity.
2022-01-07sh(1): fix formatting warningslukem
2022-01-05Use a volative local shadow of a field in an (on-stack) non-volatile structkre
that is to be referenced after a return from setjmp() via longjmp(). This doesn't ever seem to have caused a problem, but I think using volative vars is required here. For reasons I never bothered to discover, even though this change certainly requires a store into stack memory which wasn't required before, earlier measurements showed the shell getting (slightly) smaller with this change in place. NFCI
2021-12-19s/forground/foreground/ in comments.andvar
2021-12-12s/Miscelaneous/Miscellaneous/ and s/slahes/slashes/ in comments.andvar
2021-12-08s/desireable/desirable/ in comments.andvar
2021-12-05s/existance/existence/ in comment.msaitoh
2021-12-05s/commmand/command/ in comment.msaitoh
2021-11-22PR bin/53550kre
Here we go again... One more time to redo how here docs are processed (it has been a few years since the last time!) This is actually a relatively minor change, mostly to timimg (to just when things happen). Now here docs are expanded at the same time the "filename" word in a redirect is expanded, rather than later when the heredoc was being sent to its process. This actually makes things more consistent - but does break one of the ATF tests which was testing that we were (effectively) internally inconsistent in this area. Not all shells agree on the context in which redirection expansions should happen, some make any side effects visible to the parent shell (the majority do) others do the redirection expansions in a subshell so any side effcts are lost. We used to have a foot in each camp, with the majority for everything but here docs, and the minority for here docs. Now we're all the way with LBJ ... (or something like that).