CVS log for src/bin/sh/eval.h

Up to [cvs.NetBSD.org] / src / bin / sh

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

Change the "string" argument to evalstring() and setinputstring()
from being "char *" to being "const char *".

This is needed for a forthcoming change which needs to pass a const char *
to evalstring (and through it to setinputstring) and be assured that
nothing will alter the characters in the string supplied.

This is (aside from the additional compile time protection provided)
a no-op change, all evalstring() does with its string is pass it to
setinputstring() and all that does with it is determine its length
(strlen() which expects a const char *) and assign the string pointer
to parsenextc which is already a const char * - there never has been
any reason for these two functions to not include the "const" in
the arg declaration -- except that when originally written (early
1990's) I suspect "const" either didn't exist at all, or wasn't
supported by relevant compilers.

NFCI.   Most probably (though I didn't check) no binary change at all.

Ooops, restore accidently removed files from merge mishap

Sync with HEAD

Sync with HEAD

PR bin/53919

Suppress shell error messages while expanding $ENV (which also causes
errors while expanding $PS1 $PS2 and $PS4 to be suppressed as well).

This allows any random garbage that happens to be in ENV to not
cause noise when the shell starts (which is effectively all it did).

On a parse error (for any of those vars) we also use "" as the result,
which will be a null prompt, and avoid attempting to open any file for ENV.

This does not in any way change what happens for a correctly parsed command
substitution (either when it is executed when permitted for one of the
prompts, or when it is not (which is always for ENV)) and commands run
from those can still produce error output (but shell errors remain suppressed).

Sync with HEAD, resolve a few conflicts

Cleanup traps a bit - attempt to handle weird uses in traps, such
as traps that issue break/continue/return to cause the loop/function
executing when the trap occurred to break/continue/return, and
generating the correct exit code from the shell including when a
signal is caught, but the trap handler for it exits.

All that from FreeBSD.

Also make
	T=$(trap)
work as it is supposed to (also trap -p).

For now this is handled by the same technique as $(jobs) - rather
than clearing the traps in subshells, just mark them invalid, and
then whenever they're invalid, clear them before executing anything
other than the special blessed "trap" command.   Eventually we will
handle these using non-subshell command substitution instead (not
creating a subshell environ when the commands in a command-sub alter
nothing in the environment).

Sync with HEAD

Resolve a couple of conflicts (result of the uimin/uimax changes)

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

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

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

Sync with HEAD

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

PR bin/48875 - avoid holding (replaced) file descriptors open when running a
command in the current shell (so they can be restored for the next command)
in cases where it is obvious that there is not going to be a following
command to use them.   This fixes the problem reported in the PR (though
there are still plenty of situations where a FD could be closed but isn't,
we do not do full fd flow eveluation to determine whether a fd will be
used or not).

This is the change that was just committed and then backed out again...

OK christos@

Revert previous.   These changes are intended to get made (and will
be in a minute or two) but not as part of that commit...   The log
entry certainly does not apply.

Finish the fd reassignment fixes from 1.43 and 1.45 ... if we are moving
a fd to an unspecified high fd number, we certainly do not want to hand
that high fd off to other processes after an exec, so always set close-on-exec
on the result (even if lack of fd's means no fd alteration happens.)
This will (eventually) allow some other code that sets close-on-exec to
be removed, but for now, doing it twice won't hurt.   Also, in a N>&M
type redirection, do not set close-on-exec if we don't want it.

OK christos@

Rebase to HEAD as of a few days ago.

Rebase.

PR/48843: Jarmo Jaakkola: dot commands mess up scope nesting tracking

Evaluation of commands goes completely haywire if a file containing
a break/continue/return command outside its "intended" scope is sourced
using a dot command inside its "intended" scope.  The main symptom is
not exiting from the sourced file when supposed to, leading to evaluation
of commands that were not supposed to be evaluated.  A secondary symptom
is that these extra commands are not evaluated correctly, as some of them
are skipped.  Some examples are listed in the How-To-Repeat section.

According to the POSIX standard, this is how it should work:
    dot:
        The shell shall execute commands from the file in the current
        environment.
    break:
        The break utility shall exit from the smallest enclosing for, while,
        or until loop, [...]
    continue:
        The continue utility shall return to the top of the smallest
        enclosing for, while, or until loop, [...]
    return:
        The return utility shall cause the shell to stop executing
        the current function or dot script.  If the shell is not currently
        executing a function or dot script, the results are unspecified.

It is clear that return should return from a sourced file, which
it does not do.  Whether break and continue should work from the sourced
file might be debatable.  Because the dot command says "in the current
environment", I'd say yes.  In any case, it should not fail in weird
ways like it does now!

The problems occur with return (a) and break/continue (b) because:
    1)  dotcmd() does not record the function nesting level prior to
        sourcing the file nor does it touch the loopnest variable,
        leading to either
    2   a) returncmd() being unable to detect that it should not set
           evalskip to SKIPFUNC but SKIPFILE, or
        b) breakcmd() setting evalskip to SKIPCONT or SKIPBREAK,
        leading to
    3)  cmdloop() not detecting that it should skip the rest of
        the file, due to only checking for SKIPFILE.
The result is that cmdloop() keeps executing lines from the file
whilst evalskip is set, which is the main symptom.  Because
evalskip is checked in multiple places in eval.c, the secondary
symptom appears.
>How-To-Repeat:
Run the following script:

    printf "break\necho break1; echo break2" >break
    printf "continue\necho continue1; echo continue2" >continue
    printf "return\necho return1; echo return2" >return

    while true; do . ./break; done

    for i in 1 2; do . ./continue; done

    func() {
        . ./return
    }
    func

No output should be produced, but instead this is the result:
    break1
    continue1
    continue1
    return1

The main symptom is evident from the unexpected output and the secondary
one from the fact that there are no lines with '2' in them.
>Fix:
Here is patch to src/bin/sh to fix the above problems.  It keeps
track of the function nesting level at the beginning of a dot command
to enable the return command to work properly.

I also changed the undefined-by-standard functionality of the return
command when it's not in a dot command or function from (indirectly)
exiting the shell to being silently ignored.  This was done because
the previous way has at least one bug: the shell exits without asking
for confirmation when there are stopped jobs.

Because I read the standard to mean that break and continue should have
an effect outside the sourced file, that's how I implemented it.  For what
it's worth, this also seems to be what bash does.  Also laziness, because
this way required no changes to loopnesting tracking.  If this is not
wanted, it might make sense to move the nesting tracking to the inputfile
stack.

The patch also does some clean-up to reduce the amount of global
variables by moving the dotcmd() and the find_dot_file() functions from
main.c to eval.c and making in_function() a proper function.

sync with HEAD

Fix inconsistent definitions

Move UCB-licensed code from 4-clause to 3-clause licence.

Patches provided by Joel Baker in PR 22249, verified by myself.

Fixes from David Laight:
- ansification
- format of output of jobs command (etc)
- job identiers %+, %- etc
- $? and $(...)
- correct quoting of output of set, export -p and readonly -p
- differentiation between nornal and 'posix special' builtins
- correct behaviour (posix) for errors on builtins and special builtins
- builtin printf and kill
- set -o debug (if compiled with DEBUG)
- cd src obj (as ksh - too useful to do without)
- unset -e name, remove non-readonly variable from export list.
  (so I could unset -e PS1 before running the test shell...)

Revert previous change. No need to save rootshell. It is only affecting
the non-vfork case. Having said that, it would be nice if pipelines of
simple commands were vforked too. Right now they are not.
Explain that setpgid() might fail because we are doing it both in the
parent and the child case, because we don't know which one will come
first.
Suspending a pipeline prints %1 Suspended n times where n is the number
of processes, but that was there before. It is easy to fix, but I'll
leave the code alone for now.

Deal with rootshell not being maintained correctly in the vfork() case.
Propagate isroot, throughout the eval process and maintain it properly.
Fixes sleep 10 | cat^C not exiting because sleep and cat ended up in
their own process groups, because wasroot was always true in the children.

Fix bin/9184, bin/9194, bin/9265, bin/9266
Exitcode and negation problems (From Martin Husemann)

Fix return builtin to work like it does in ksh:
When not in a function, it skips the rest of the current input file.
Instances of `return' outside function definitions were previously ignored.
What does joe posix have to say about this?
[fixes PR/1444]

Merge in my changes from vangogh, and fix the x=`false`; echo $? == 0
bug.

convert to new RCS id conventions.

Add RCS ids.

sync with 4.4lite

44lite code

Add RCS identifiers.

changed "Id" to "Header" for rcsids

added rcs ids to all files

initial import of 386bsd-0.1 sources

Initial revision