"type" may return incorrect information after posix mode is enabled
With the current git head (and 4.3):
$ ./bash -c 'eval() { echo function; }; set -o posix; type eval; eval echo not
function'
eval is a function
eval ()
{
echo function
}
not function
$ ./bash --version
GNU bash, version 4.4.0(1)-alpha (x86_64-unknown-linux-gnu)
[...]
"type eval" should return
eval is a shell builtin
there since the special builtin takes precedence over functions
in POSIX mode.
(actually, having "eval is a special shell builtin" like in
dash/mksh/ksh93/yash would be nice)
--
Stephane
Re: "type" may return incorrect information after posix mode is enabled
On 07/21/2015 05:07 AM, Stephane Chazelas wrote:
> With the current git head (and 4.3):
>
> $ ./bash -c 'eval() { echo function; }; set -o posix; type eval; eval echo
> not function'
'eval' is a special built-in, and as such, cannot be usefully defined as
a function, because the shell rules for determining which command to
execute favor special built-ins over functions.
If anything, it would be nice if bash errored out on the attempt to
define a function named 'eval', rather than allowing it to succeed.
> (actually, having "eval is a special shell builtin" like in
> dash/mksh/ksh93/yash would be nice)
Yes, distinguishing between special and other built-ins would indeed be
nice.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: "type" may return incorrect information after posix mode is enabled
2015-07-21 08:07:15 -0600, Eric Blake:
> On 07/21/2015 05:07 AM, Stephane Chazelas wrote:
> > With the current git head (and 4.3):
> >
> > $ ./bash -c 'eval() { echo function; }; set -o posix; type eval; eval echo
> > not function'
>
> 'eval' is a special built-in, and as such, cannot be usefully defined as
> a function, because the shell rules for determining which command to
> execute favor special built-ins over functions.
Only in posix mode for bash though. I find that POSIX requirement
silly (probably specifies a limiation found in ksh). zsh also
ignores it.
> If anything, it would be nice if bash errored out on the attempt to
> define a function named 'eval', rather than allowing it to succeed.
[...]
It does error-out when in POSIX mode.
My test case was for the case where the function is defined in
non-posix mode, but type invoked in posix mode.
So, it's a very minor issue as probably unlikely to harm anyone.
--
Stephane
RE: "type" may return incorrect information after posix mode is enabled
Bash will report error if you define function, which named the same as special
builtin commands, in POSIX mode:
$ bash --norc --posix$ bash-4.3$ eval() { echo func;}bash: `eval': is a special
builtin
The problem here is bash doesn't forget those type of functions if they were
defined before POSIX mode enabled.
-- Mr. LE Manh CuongMobile: +84 1216 181090Skype: manhcuongle> Subject: Re:
"type" may return incorrect information after posix mode is enabled
> To: stephane.chaze...@gmail.com; bug-bash@gnu.org
> From: ebl...@redhat.com
> Date: Tue, 21 Jul 2015 08:07:15 -0600
>
> On 07/21/2015 05:07 AM, Stephane Chazelas wrote:
> > With the current git head (and 4.3):
> >
> > $ ./bash -c 'eval() { echo function; }; set -o posix; type eval; eval echo
> > not function'
>
> 'eval' is a special built-in, and as such, cannot be usefully defined as
> a function, because the shell rules for determining which command to
> execute favor special built-ins over functions.
>
> If anything, it would be nice if bash errored out on the attempt to
> define a function named 'eval', rather than allowing it to succeed.
>
> > (actually, having "eval is a special shell builtin" like in
> > dash/mksh/ksh93/yash would be nice)
>
> Yes, distinguishing between special and other built-ins would indeed be
> nice.
>
> --
> Eric Blake eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
Re: Bug where SIGINT trap handler isn't called
On 7/16/15 12:05 AM, Patrick Plagwitz wrote: >> This is another case of the scenario most recently described in >> >> http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00108.html >> >> In this case, python appears to catch the SIGINT (it looks like a >> KeyboardInterrupt exception), print the message, and exit with status 1. >> >> Chet >> > > Ok, I see. > However, there appears to be some race condition when waiting for a > command substitution. > I have the attached combination of scripts. > > When run with > $ bash run-until-end-of-loop.sh bash start-subst-loop.sh '2>/dev/null' > , the script will try to launch and SIGINT subst-loop.sh repeatedly > until the SIGINT trap is once *not* called which will happen in at most > 200 repetitions on my machine. The script then ends after printing “end > of loop”. The python script execute-with-sigint.py is only there to > enable subst-loop.sh to receive a SIGINT at all. > subst-loop.sh calls date(1) in a loop; date should have SIGINT set to > SIG_DFL other than python initially. > > I analyzed the execution by inserting some debug output into the bash > code. It seems that in the case that the SIGINT trap is not called > subst-loop.sh gets the SIGINT while (or shortly before or after) calling > waitpid in waitchld:jobs.c which will then return without errno == > EINTR. The wait_sigint_handler will be called, though, and so > wait_sigint_received will be true. This doesn't agree with what I see on RHEL6. I get waitpid() returning -1/ EINTR, which bash interprets, using a heuristic, to mean that the child blocked or caught SIGINT, in which case bash should not act as if it received it. There is a small race condition here, which is very hard to close while maintaining the desired behavior: bash only responds to SIGINT received while waiting for a child if the child exits due to SIGINT. You appear to have hit it: the timing of the ^C is such that waitpid returns -1/EINTR, causing the shell to ignore the ^C. I suspect this is because the child called exit(0) before the ^C arrived and the shell got the signal, but the child exited successfully, causing the shell to assume the child blocked or caught the SIGINT. That heuristic was developed as the result of an extensive discussion between me and several Linux kernel developers back in 2011. You can read that here: http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00050.html http://lists.gnu.org/archive/html/bug-bash/2011-03/msg0.html I will look at the signal handler race condition you identified. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
