Debian: bash --debugger doesn't start the debugger
My investigations indicate that it is still true that as per Debian bug report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403304) --debugger does NOT start the debugger UNLESS the debugged script has a $1. For example /bin/bash --debugger -- ~/scripts/ex1.sh will just run the script but /bin/bash --debugger -- ~/scripts/ex1.sh XXX will enter the debugger. To comment on the other prior information on the Debian bug report: 1. The upstream bashdb developer is correct that checking "strings `which bash` | grep bashdb" is a good test for whether bash will find bashdb-main.inc, but this is not relevant to Debian becase this is set correctly in Debian's case. 2. If you take an upstream tarball of bash and compile it then even the extra $1 will not make the debugger run under that bash, unless you link the upsteram location of '/usr/local/share/bashdb' to the Debian value of /usr/share/bashdb. In other words the other commenters were correct but had not got to the root issue. The root issue is appears to be this line in shell.c in the bash code: if (debugging_mode && locally_skip_execution == 0 && running_setuid == 0 && dollar_vars[1]) start_debugger (); I enclose a patch that I believe would address this, and suggest it is an upstream bash issue. Description: correct check on $0 in conditions for entering debugger Author: Nicholas Bamber Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403304 Last-Update: 2015-10-12 Index: bash-4.3/shell.c === --- bash-4.3.orig/shell.c +++ bash-4.3/shell.c @@ -720,7 +720,7 @@ main (argc, argv, env) /* Bind remaining args to $1 ... $n */ arg_index = bind_args (argv, arg_index, argc, 1); - if (debugging_mode && locally_skip_execution == 0 && running_setuid == 0 && dollar_vars[1]) + if (debugging_mode && locally_skip_execution == 0 && running_setuid == 0 && dollar_vars[0]) start_debugger (); /* Do the things that should be done only for interactive shells. */
Re: read and env variables + POSIX => SEGFAULT
On Mon, Oct 12, 2015 at 04:39:45PM -0700, Linda Walsh wrote: > I wasn't sure if it put the "\n" at the end in a 1-line example. << and <<< always end with a trailing newline. This is 100% unavoidable with that syntax. If your data stream needs NOT to end with a newline, then you have to use < <(printf ...). > Does it also use a tmp file and use process-substitution, or is > that only when parens are present? Yes, <<< uses a temp file just like << does. wooledg@wooledg:~$ (sleep 1; ls -l /dev/fd/0; sleep 10) <<< "a temp string" lr-x-- 1 wooledg wooledg 64 Oct 13 08:09 /dev/fd/0 -> /tmp/sh-thd-1033352477 (deleted) One that is opened and then unlinked, as it turns out.
Re: Debian: bash --debugger doesn't start the debugger
On 10/12/15 4:16 PM, Nicholas Bamber wrote: > My investigations indicate that it is still true that as per Debian bug > report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403304) > --debugger does NOT start the debugger UNLESS the debugged script has a $1. We discussed this in a thread on bug-bash back in April: http://lists.gnu.org/archive/html/bug-bash/2015-04/msg00183.html This discussion references an earlier bug report concerning whether the --debugger option should produce an error if the bashdb script is not installed. There is also an issue with bashdb misbehaving when run in an interactive shell; that was the reason for the check of $1 in the first place. Part of that thread explains why a check of $0 is not correct: since $0 is always set, a check for it has no effect. The final change that solves both problems went into the bash development branch in early May, and will be in bash-4.4. -- ``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/
Re: command substitution is stripping set -e from options
On 10/13/15 2:04 AM, Christoph Gysin wrote: > On Sat, Oct 10, 2015 at 8:24 PM, Chet Ramey wrote: >> I will consider adding an option to change the behavior of command >> substitution inheriting the -e option, since there doesn't seem to be >> any way to decouple this behavior from posix mode. > > I added a patch: > https://savannah.gnu.org/patch/index.php?8769 Thanks; I'll take a look. 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/
Re: Want way to run background processes with SIGINT unignored
Ian Jackson writes ("Re: Want way to run background processes with SIGINT
unignored"):
> Chet Ramey writes ("Re: Want way to run background processes with SIGINT
> unignored"):
> > This is the behavior that any new option would toggle. Some name like
> > `async_sig_ignore' or `async_sig_restore' would work.
>
> Thanks for your attention and your feedback; I'll get back to you with
> a patch.
This patch is nearly ready and I will send it shortly.
While I was working on the docs aspect I noticed an infelicity in the
documentation. It generally talk about the signal disposition that
the shell `inherits from its parent'. For example:
traps caught by the shell are reset to the values inherited from the
shell's parent, and traps ignored by the shell are ignored
But this is misleading. The values that the signals are reset to are
those which the parent inherited _at shell invocation_ (ie, at exec).
If the shell is a subshell (produced with `( )' perhaps), it may have
inherited different settings from its _parent_ (ie, the main shell).
I think this wording should be changed throughout to read `inherited
at shell invocation'. Do you agree ? Would you welcome a patch along
those lines ?
Thanks,
Ian.
Re: Something strange with string replacements
Thanks Greg!
You're the best, didn't notice that. I'm testing globasciiranges, it behaves
like the C locale and that's very interesting.
Thanks again, I really appreciate your explanation.
El lunes, 12 de octubre de 2015, 1:33:11 (UTC+2), gaspa...@gmail.com escribió:
> Hello,
>
> I was just testing if I could do some things with bash and the I came across
> this:
> $ tigres="Un tigre, dos tigres, tres tigres"
> $ echo ${tigres//[A-Z]/[a-z]}
>
> tt [a-z][a-z][a-z][a-z][a-z], Ale cto kkk log nfs tes tmp tst www
> [a-z][a-z][a-z][a-z][a-z][a-z], aeat home kaka lmms Mail prog temp test
> Clases kernel kfreir Mariah Música system unbind Vídeos webdav
>
> The reply was strange, Ale, cto, kkk, log, nfs, tes... are files in the
> current directory where I'm running this.
>
> I was just testing, not trying to convert letters or so.
>
> My bash Version: GNU bash, versión 4.3.11(1)-release (x86_64-pc-linux-gnu)
>
> Thanks
[PATCH] Provide shopt -s no_async_sig_ignore
This option disables the standards-mandated resetting of SIGINT (and
QUIT) to SIG_IGN in asynchronous children.
This resetting makes it very hard to write a bash script which invokes
a number of subprocesses in parallel and collects the output. The
problem is that if you ^C the script, the subprocesses carry on
running (doing needless work and perhaps causing lossage).
Working around this in a race-free way with additional code in the
script is very hard indeed. However, we can provide an option to do
the right thing in modern programs.
(The reason for SIGINT being ignored is purely historical: back in the
dawn of time, there was no job control. If you interactively spawned
a background process with &, you wouldn't want your attempts to ^C
your foreground process to kill it. This SIGINT-ignoring also applied
to noninteractive shells and of course came to be relied on. So it is
too late to change the default.)
Signed-off-by: Ian Jackson
Signed-off-by: Ian Jackson
CC: Ian Campbell
---
MANIFEST| 3 +++
builtins/shopt.def | 2 ++
doc/bash.1 | 10 ++
doc/bashref.texi| 13 -
execute_cmd.c | 5 -
tests/asyncsigint.right | 6 ++
tests/asyncsigint.tests | 27 +++
tests/run-asyncsigint | 2 ++
tests/shopt.right | 3 +++
9 files changed, 69 insertions(+), 2 deletions(-)
create mode 100644 tests/asyncsigint.right
create mode 100644 tests/asyncsigint.tests
create mode 100644 tests/run-asyncsigint
diff --git a/MANIFEST b/MANIFEST
index 55c8d1c..1c3106c 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -841,6 +841,8 @@ tests/assoc4.subf
tests/assoc5.sub f
tests/assoc6.sub f
tests/assoc7.sub f
+tests/asyncsigint.testsf
+tests/asyncsigint.rightf
tests/braces.tests f
tests/braces.right f
tests/builtins.tests f
@@ -1107,6 +1109,7 @@ tests/run-arith f
tests/run-arrayf
tests/run-array2 f
tests/run-assocf
+tests/run-asyncsigint f
tests/run-braces f
tests/run-builtins f
tests/run-case f
diff --git a/builtins/shopt.def b/builtins/shopt.def
index 6050a14..89a9aae 100644
--- a/builtins/shopt.def
+++ b/builtins/shopt.def
@@ -90,6 +90,7 @@ extern int autocd;
extern int glob_star;
extern int glob_asciirange;
extern int lastpipe_opt;
+extern int no_async_sig_ignore_opt;
#if defined (EXTENDED_GLOB)
extern int extended_glob;
@@ -199,6 +200,7 @@ static struct {
#endif
{ "login_shell", &shopt_login_shell, set_login_shell },
{ "mailwarn", &mail_warning, (shopt_set_func_t *)NULL },
+ { "no_async_sig_ignore", &no_async_sig_ignore_opt, (shopt_set_func_t *)NULL
},
#if defined (READLINE)
{ "no_empty_cmd_completion", &no_empty_command_completion, (shopt_set_func_t
*)NULL },
#endif
diff --git a/doc/bash.1 b/doc/bash.1
index 2b1ca15b..f318ab1 100644
--- a/doc/bash.1
+++ b/doc/bash.1
@@ -9535,6 +9535,16 @@ If set, and a file that \fBbash\fP is checking for mail
has been
accessed since the last time it was checked, the message ``The mail in
\fImailfile\fP has been read'' is displayed.
.TP 8
+.B no_async_sig_ignore
+If set in a noninteractive shell, asynchronous commands will
+not have
+.B SIGINT
+and
+.BR SIGQUIT
+ignored;
+instead, those signals' handlers will be reset to those
+inherited by the shell from its parent, as for other signals.
+.TP 8
.B no_empty_cmd_completion
If set, and
.B readline
diff --git a/doc/bashref.texi b/doc/bashref.texi
index 597274b..2556b60 100644
--- a/doc/bashref.texi
+++ b/doc/bashref.texi
@@ -3060,7 +3060,10 @@ Non-builtin commands started by Bash have signal
handlers set to the
values inherited by the shell from its parent.
When job control is not in effect, asynchronous commands
ignore @code{SIGINT} and @code{SIGQUIT} in addition to these inherited
-handlers.
+handlers,
+unless the shell option @code{no_async_sig_ignore}
+(see the description of @code{shopt} in @ref{The Shopt Builtin})
+is enabled.
Commands run as a result of
command substitution ignore the keyboard-generated job control signals
@code{SIGTTIN}, @code{SIGTTOU}, and @code{SIGTSTP}.
@@ -5146,6 +5149,14 @@ If set, and a file that Bash is checking for mail has
been
accessed since the last time it was checked, the message
@code{"The mail in @var{mailfile} has been read"} is displayed.
+@item no_async_sig_ignore
+If set in a noninteractive shell, asynchronous commands will not
+have
+@code{SIGINT} and @code{SIGQUIT}
+ignored;
+instead, those signals' handlers will be reset to those
+inherited by the shell from its parent, as for other signals.
+
@item no_empty_cmd_completion
If set, and Readline is being used, Bash will not attempt to search
the @env{PATH} for possible completions when completion is attempted
diff --git a/execute_cmd.c b/execute_cmd.c
index 9cebaef..c3b30b6 100644
--- a/execute_cmd.c
+++ b/execute_cmd.c
@@ -287,6 +287,7 @@ int funcnest = 0;
int func
bash 4.3.42 configure script needs to test sys/resource.h different on SunOS4
Configuration Information [Automatically generated, do not change]:
Machine: m68k
OS: sunos4.1.1_U1
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='m68k'
-DCONF_OSTYPE='sunos4.1.1_U1' -DCONF_MACHTYPE='m68k-sun-sunos4.1.1_U1'
-DCONF_VENDOR='sun' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -DSunOS4 -I. -I. -I./include -I./lib
-I./lib/intl -I/export/home/klausz/src/bash-4.3.30/lib/intl -O2
uname output: SunOS suntools 4.1.1_U1 1 sun3x
Machine Type: m68k-sun-sunos4.1.1_U1
Bash Version: 4.3
Patch Level: 42
Release Status: release
Description:
if running the configure script on SunOS4 the following WARNING occurs:
./configure `cat /export/home/klausz/src/conf_bash-4.3.30`
checking build system type... m68k-sun-sunos4.1.1_U1
checking host system type... m68k-sun-sunos4.1.1_U1
Beginning configuration for bash-4.3-release for m68k-sun-sunos4.1.1_U1
checking for gcc... gcc
...
checking sys/resource.h usability... no
checking sys/resource.h presence... yes
configure: WARNING: sys/resource.h: present but cannot be compiled
configure: WARNING: sys/resource.h: check for missing prerequisite
headers?
configure: WARNING: sys/resource.h: see the Autoconf documentation
configure: WARNING: sys/resource.h: section "Present But Cannot Be
Compiled"
configure: WARNING: sys/resource.h: proceeding with the compiler's result
configure: WARNING: ## --- ##
configure: WARNING: ## Report this to bug-bash@gnu.org ##
configure: WARNING: ## --- ##
checking for sys/resource.h... no
...
checking for snprintf... no < no warning here - but!
...
this leads to the following compilation errors later on:
gcc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"m68k"'
-DCONF_OSTYPE='"sunos4.1.1_U1"'
-DCONF_MACHTYPE='"m68k-sun-sunos4.1.1_U1"' -DCONF_VENDOR='"sun"'
-DLOCALEDIR='"/usr/share/locale"' -DPACKAGE='"bash"' -DSHELL
-DHAVE_CONFIG_H -DSunOS4 -I. -I. -I./include -I./lib -I./lib/intl
-I/export/home/klausz/src/bash-4.3.30/lib/intl -O2 -O2 -O2 -o
bashversion ./support/bashversion.c buildversion.o
ld: Undefined symbol
_snprintf
collect2: ld returned 2 exit status
gmake: *** [bashversion] Error 1
...
gcc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"m68k"'
-DCONF_OSTYPE='"sunos4.1.1_U1"'
-DCONF_MACHTYPE='"m68k-sun-sunos4.1.1_U1"' -DCONF_VENDOR='"sun"'
-DLOCALEDIR='"/usr/share/locale"' -DPACKAGE='"bash"' -DSHELL
-DHAVE_CONFIG_H -DSunOS4 -I. -I. -I./include -I./lib -I./lib/intl
-I/export/home/klausz/src/bash-4.3.30/lib/intl -O2 -c execute_cmd.c
execute_cmd.c: In function `time_command':
execute_cmd.c:1268: storage size of `selfb' isn't known
execute_cmd.c:1268: storage size of `selfa' isn't known
execute_cmd.c:1268: storage size of `kidsb' isn't known
execute_cmd.c:1268: storage size of `kidsa' isn't known
execute_cmd.c:1282: `RUSAGE_SELF' undeclared (first use in this function)
execute_cmd.c:1282: (Each undeclared identifier is reported only once
execute_cmd.c:1282: for each function it appears in.)
execute_cmd.c:1283: `RUSAGE_CHILDREN' undeclared (first use in this
function)
gmake: *** [execute_cmd.o] Error 1
Hi Chet,
I have no clue how to fix the bashversion linking error in the configure
script, besides modifying config.h after
configure has done it's work. However, the compile error in
execute_cmd.c, is directly related to the failed
autoconf test for from above. On SunOS4 a test for
/usr/include/sys/resource.h needs to
include /usr/include/sys/time.h to be successful.
from config.log:
configure:9287: checking sys/resource.h usability
configure:9287: gcc -c -O2 conftest.c >&5
In file included from conftest.c:147:
/usr/include/sys/resource.h:24: field `ru_utime' has incomplete type
/usr/include/sys/resource.h:25: field `ru_stime' has incomplete type
configure:9287: $? = 1
from /usr/include/sys/resource.h:
23 struct rusage {
24 struct timeval ru_utime;/* user time used */
25 struct timeval ru_stime;/* system time used */
from /usr/include/sys/time.h:
16 struct timeval {
17 longtv_sec; /* seconds */
18 longtv_usec;/* and microseconds */
19 };
including before checking works.
Other useful information:
configure options used:
--enable-help-builtin --enable-history --enable-job-control
--enable-multibyte --enable-process-substitution --enable-progcomp
--enable-prompt-string-decoding --enable-readline --enable-select
--enable-xpg-echo-default --enable-alias --enable-arith-for-command
--enable-array-variables --enable-bang-history --enable-brace-expansion
--enable-casemod-attributes --enable-casemod-expansions
--enable-command-timing --enable-cond-command --enable-cond-regexp
--enable-coprocesses --enable-direxpand-default --enable-directory-stack
--enable-dparen-arithmetic --enable-extended-glob
--enable-extended-glob-default --enable-glob-asciiranges-default
--prefix
my confusion on various I/O redirections syntaxes and indirect methods
Chet Ramey wrote:
On 10/12/15 7:39 PM, Linda Walsh wrote:
Does it also use a tmp file and use process-substitution, or is
that only when parens are present?
Here-documents and here-strings use temporary files and open them as
the standard input (or specified file descriptor) for the command.
read a < <( echo x)
I'm under the impression, uses a tmp file.
Why would you think that?
Well, we have
"<< xxx"
as a HERE DOC using a tmp file, Some time ago, the ability to do
"multiple assignments" at the same time was added (when I asked how to
do that) that was told to use:
"read x y z <<< "one two three"
(which I initially equated to something like:
(x y z)=(one two three)
That would be like the regular assignment:
xyz=(one two three)
but with the array syntax on the left, would do word
splitting on the left and assign to the individual vars;
as I was searching for a way to do multiple assignments
in the same statement).
Then came along a way to do a process in background and end up
with being able to read & process its data in the main (foreground)
process w/this syntax:
readarray -t foregnd < <(echo $'one\ntwo\nthree')
Which I envisioned as
as implemented something like (C-ish example
off top of head using a perl-code I wrote to do the same):
int savein,saveout;
int pid;
dup2(0, savein);
dup2(1, saveout);
int inout[2];
#define stdin inout[0]
#define stdout inout[1]
pipe(&inout,O_NONBLOCK);
dupto(stdin,0);
dupto(stdout,1);
setup_childsighandler(to close 0 when child exits);
if ($pid=fork()) { #parent
dupto(saveout,1);
shell("readarray -t uservar("xyz")"); #reads from pipe:inout[0]
#child handler closes 0
dupto(savein,0);
} else if (pid==0) { #child
close(0);
shell("echo $'a\nb\nc'"); #output goes out on pipe:inout[1]
exit(0);
}
##parent continues -- no tmpfiles or named fifo's needed.
---
So I didn't realize instead of doing it simply using
native pipes like above, it was implemented some other way.
didn't understand the complexity of the need
for < <( to need a named pipe or fifo)
These examples and concepts came up when I
was trying to write a bash script that threw
out some error cases like /dev/fd/99 not found... or such
or implemented some other way /tmp/foobar not found...
(both of which I thought were mounted, but wasn't sure --
but then wondered why a tmpfile or named pipe was
needed for EITHER implementation... both can
be done with native pipes like above, no external
"linux-isms" or files needed -- and I'm certain
the execution speed would be no worse (likely
better than using tmp files or named pipes/fifos).
The documentation clearly says it uses a named
pipe or a file descriptor associated with a /dev/fd filename (which happens
to be a pipe in this case).
yeah with the clear and unambiguous syntax
of :
<< xxx
<<< xxx
<<< $(echo 'xxx')
< < (xxx)
I can't imagine why'd I ever have been confused -- or,
given the pipe example above -- why any of the above
had to use "pathname" based io.
So the fact that I get confused about what extra-complex
is used for which syntax isn't that surprising to me --
is it that surprising to you that given the complexities
chosen for implementation, why some people might be
confused about remembering the details of each when
they all could have been done without any pathname
confusions??
Re: my confusion on various I/O redirections syntaxes and indirect methods
On Tue, Oct 13, 2015 at 01:51:03PM -0700, Linda Walsh wrote: > Well, we have > "<< xxx" > as a HERE DOC using a tmp file Correct. Note that xxx is just the sentinel to tell bash where the here document ends. It's not part of the data. > , Some time ago, the ability to do > "multiple assignments" at the same time was added (when I asked how to > do that) You are confused. Nothing was added. > that was told to use: > > "read x y z <<< "one two three" This is simply how the read commands works. If you give read three variable names, it will break the line into fields (assuming IFS is not empty) and assign the first field to the the first variable, the second field to the second variable, and THE ENTIRE REMAINING LINE (delimiters and all!) to the third variable. > (which I initially equated to something like: > (x y z)=(one two three) You are mixing things up. There are two different pieces of syntax here: the read command, and the here string syntax. The here string syntax <<< is exactly like a here document << except that the here string is a single word terminated by a newline (or by quoting) instead of by a specified delimiter. The following two pieces of code are exactly the same: read x y z <<< "an input string" read x y z << EOF an input string EOF Moreover, the following two pieces of code give the same resulting variable contents: read x y z <<< "a much longer input string" read x y z << EOF a much longer input string with some other lines after it EOF In both cases, z="longer input string". The extra lines in the second code piece are not used, because read stops reading at the first newline. > Then came along a way to do a process in background and end up > with being able to read & process its data in the main (foreground) > process w/this syntax: > > readarray -t foregnd < <(echo $'one\ntwo\nthree') This is process substitution. It's not like here documents/here strings which use a temp file and syntactic delimiters. It runs a command in the background and establishes a named pipe (or uses a /dev/fd/* entry, depending on the platform) to connect the background process to the foreground command. The <(...) construction is replaced by the name of the FIFO or the /dev/fd/* entry. So as far as the foreground command is concerned, it is simply an input redirection: readarray -t foregnd < something The "something" happens to be a magical pipe/fd thing, that's all. The key is that it's somewhere in the file system, which allows an input redirection to point to it. readarray doesn't know anything magical is happening. It just reads standard input.
