(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.
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.
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.
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 ...)
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@
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
standardised the table from V7. Nobody, including the original authors,
seems to have noticed this. Merge them and update the documentation.
Also fix the odd, inconsistent, spelling of "pre-4.3BSD-Reno").
(From nabijaczleweli)
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.
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
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).
all the sh options, also used with "set", are listed) in response to
a discussion on icb conveyed to me by Darrin B. Jewell.
A few improvements to the description of the "set" built-in as well.
Bump Dd to cover all of this month's changes (so far).
Make "hash" exit(!=0) (ie: exit(1)) if it writes an error message to
stderr as required by POSIX (it was writing "not found" errors, yet
still doing exit(0)).
Whether, when doing "hash foobar", and "foobar" is not found as a command
(not a built-in, not a function, and not found via a PATH search), that
should be considered an error differs between shells. All of the ksh
descendant shells say "no", write no error message in this case, and
exit(0) if no other errors occur. Other shells (essentially all) do
consider it an error, write a message to stderr, and exit(1) when this happens.
POSIX isn't clear, the bug report:
https://austingroupbugs.net/view.php?id=1460
which is not yet resolved, suggests that the outcome will be that
this is to be unspecified. Given the diversity, there might be no
other choice.
Have a foot in both camps - default to the "other shell" behaviour,
but add a -e option (no errors ... applies only to these "not found"
errors) to generate the ksh behaviour. Without other errors (like an
unknown option, etc) "hash -e anyname" will always exit(0).
See the PR for details on how it all works now, or read the updated man page.
While here, when hash is in its other mode (reporting what is in the
table) check for I/O errors on stdout, and exit(1) (with an error
message!) if any occurred. This does not apply to output generated
by the -v option when command names are given (that output is incidental).
In sh.1 document all of this. Also add documentation for a bunch of
other options the hash command has had for years, but which were never
documented. And while there, clean up some other sections I noticed
needed improving (either formatting or content or both).
This affects (as best I can tell) only uses of ${LINENO} in PS4
when -x is enabled (and perhaps only when the list contains no
expansions). "for" like "case" (which was already handled) is
special in that it generates trace output before actually executing
any kind of simple command.
identified with the -u flag (that is, I hope I identified all
the ones that were missing it).
This change is a no-op (NFC) as the -u flag does nothing.
Still, just in case we find a use for it one day, and just as a
matter of general principle, we should get this correct.
echo.c: In function 'main':
echo.c:74:1: warning: control reaches end of non-void function
This raises 2 issues.
First, why with WARNS set to 6, which should include just about
everything, was this not causing problems with everyday builds?
Surely falling off the end of a non-void function without returning
a specific value is one of the more basic errors that should be fixed.
(Whatever the name of the function). Is there a missing -Wxxx option?
And second, does C99 really promise:
Remove unnecessary call to exit(0); returning from main is equivalent
since C99.
in the sense that simply falling out of main() is exit(0)? Or is it
simply saying that the return value of main() is the exit status (which
has been true for much longer than since c99)?
Mostly adding DEBUG mode tracing (when appropriate verbose tracing
is enabled generally) whenever a shell (including sushell) process
exits, so shells that the tracing should indicate why ehslls that
vanish did that.
Note for future investigators: if the relevant tracing is enabled,
and a (sub-)shell still simply seems to have vanished without trace,
the likely cause is that it was killed by a signal - and of those,
the most common that occurs is SIGPIPE.
andvar