Problem with small script
The script: #/bin/bash # testlink.sh # must be run as root file1="$1" shift mandir=/usr/local/share/man/man3/ cp "$file1" "$mandir" cd "$mandir" echo '$hash = '"$#" while (( "$#" )); do file2="$1" ln "$file1" "$file2" shift done Results: >> sudo ./testlink.sh readfile.3 readtextfile.3 $hash = 1 ./testlink.sh: 11: ./testlink.sh: 1: not found >> Bash version: 4.3.11(1)-release (x86_64-pc-linux-gnu) Any help appreciated, Thanks. -- The Bundys, Cliven, Ted and Al. Great guys to look up to.
Re: Problem with small script
On Thu, Feb 18, 2016 at 11:06:37PM +0700, Robert Parker wrote: > The script: > #/bin/bash > # testlink.sh > # must be run as root > > file1="$1" > shift > mandir=/usr/local/share/man/man3/ > cp "$file1" "$mandir" > cd "$mandir" You MUST check the result of cd. If it fails but you continue on, you will be operating in the wrong place. > echo '$hash = '"$#" > while (( "$#" )); do > file2="$1" > ln "$file1" "$file2" > shift > done > > Results: > >> sudo ./testlink.sh readfile.3 readtextfile.3 > $hash = 1 > ./testlink.sh: 11: ./testlink.sh: 1: not found > >> As near as I can tell, you are somehow running this script under sh instead of bash. wooledg@wooledg:~$ cat foo #!/bin/bash while (( "$#" )); do shift done wooledg@wooledg:~$ ./foo wooledg@wooledg:~$ sh ./foo ./foo: 2: ./foo: 0: not found Maybe you forgot to give it execute permissions, and therefore sudo runs sh for you or something. That's just a wild guess. (Can't reproduce that on my system.) But whatever the reason, the behavior you're seeing is fully consistent with executing it under the wrong shell.
Re: Problem with small script
On Thu, Feb 18, 2016 at 11:30 PM, Greg Wooledge wrote: > On Thu, Feb 18, 2016 at 11:06:37PM +0700, Robert Parker wrote: > > The script: > > #/bin/bash > > # testlink.sh > > # must be run as root > > > > file1="$1" > > shift > > mandir=/usr/local/share/man/man3/ > > cp "$file1" "$mandir" > > cd "$mandir" > > You MUST check the result of cd. If it fails but you continue on, > you will be operating in the wrong place. > Fair comment, but this has worked properly in an earlier version that did not rely on using *shift.* > > > echo '$hash = '"$#" > > while (( "$#" )); do > > file2="$1" > > ln "$file1" "$file2" > > shift > > done > > > > Results: > > >> sudo ./testlink.sh readfile.3 readtextfile.3 > > $hash = 1 > > ./testlink.sh: 11: ./testlink.sh: 1: not found > > >> > > As near as I can tell, you are somehow running this script under sh > instead of bash. > > wooledg@wooledg:~$ cat foo > #!/bin/bash > while (( "$#" )); do > shift > done > wooledg@wooledg:~$ ./foo > wooledg@wooledg:~$ sh ./foo > ./foo: 2: ./foo: 0: not found > > Maybe you forgot to give it execute permissions, and therefore sudo > runs sh for you or something. That's just a wild guess. (Can't > reproduce that on my system.) But whatever the reason, the behavior > you're seeing is fully consistent with executing it under the wrong > shell. > Not so: chmod +x testlink.sh always. The wild card here is that I am running it under sudo because I am installing a man page in /usr/local/share/man/man3 and trying to link other names to said man page. Is there any way I can tell which shell is running? the top line in the script is #/bin/bash Is there any way I can tell which shell is in control? Thanks for your response. Bob -- The Bundys, Cliven, Ted and Al. Great guys to look up to.
Re: Problem with small script
On Thu, Feb 18, 2016 at 05:58:28PM +0100, baldu...@units.it wrote: > > On Thu, Feb 18, 2016 at 11:06:37PM +0700, Robert Parker wrote: > > > The script: > > > #/bin/bash > ^ missing ! here > > typo in the shebang? Yes, nicely done. I missed that. On Fri, Feb 19, 2016 at 12:22:20AM +0700, Robert Parker wrote: > On Thu, Feb 18, 2016 at 11:30 PM, Greg Wooledge wrote: > > You MUST check the result of cd. If it fails but you continue on, > > you will be operating in the wrong place. > > Fair comment, but this has worked properly in an earlier version that did > not rely on using *shift.* It's a separate and more subtle issue. It's not the cause of the visible problem. It's a lurking, insidious bug that will strike in the future. > > > while (( "$#" )); do When you run this command under sh (due to the shebang error, as mentioned above), it isn't an arithmetic evaluation. It's just a subshell with an extra set of inner parentheses. When you run ./myscript in bash, the missing shebang is caught as an "exec format error" by the kernel. Bash sees that, and runs it in another instance of bash. sudo apparently sees the exec format error, and runs it in sh. (But you might want to look into that. I'm not an expert on sudo.)
Re: Problem with small script
On Fri, Feb 19, 2016 at 12:45 AM, Greg Wooledge wrote: > On Thu, Feb 18, 2016 at 05:58:28PM +0100, baldu...@units.it wrote: > > > On Thu, Feb 18, 2016 at 11:06:37PM +0700, Robert Parker wrote: > > > > The script: > > > > #/bin/bash > > ^ missing ! here > > > > typo in the shebang? > > Yes, nicely done. I missed that. > > > On Fri, Feb 19, 2016 at 12:22:20AM +0700, Robert Parker wrote: > > On Thu, Feb 18, 2016 at 11:30 PM, Greg Wooledge > wrote: > > > You MUST check the result of cd. If it fails but you continue on, > > > you will be operating in the wrong place. > > > > Fair comment, but this has worked properly in an earlier version that did > > not rely on using *shift.* > > It's a separate and more subtle issue. It's not the cause of the > visible problem. It's a lurking, insidious bug that will strike in > the future. > > > > > while (( "$#" )); do > > When you run this command under sh (due to the shebang error, as mentioned > above), it isn't an arithmetic evaluation. It's just a subshell with > an extra set of inner parentheses. > > When you run ./myscript in bash, the missing shebang is caught as > an "exec format error" by the kernel. Bash sees that, and runs it in > another instance of bash. > > sudo apparently sees the exec format error, and runs it in sh. (But you > might want to look into that. I'm not an expert on sudo.) > You are right on the money! Under sudo I am running sh other wise bash but being not root it has other failures. But to put it to bed. All the grief came from the missing '!' Once in place it works. Under sudo it does run sh but otherwise runs bash. Glad your eyes are better than mine, and thanks! Bob -- The Bundys, Cliven, Ted and Al. Great guys to look up to.
Bug with declarative arrays
Hello everybody,
I believe I have a relevant bug to report. My company uses bash extensively and
we would like to contribute!
The bug I found is related to the possibility of obtaining all keys of a
declarative array at once (${!ARRAY[@]} syntax). It seems that every time such
a call is done there is memory allocation, which is NOT deallocated when the
corresponding scope ends. This produces a memory leak.
In the attachment there is a simple script with an endless loop. As long as it
runs the memory usage will increase.
SYSTEM:
- Debian 8 linux kernel 3.16.0-4-amd64
- Bash version 4.3.30(1) x86_64-pc-linux-gnu
I also search the documentation to see I was misusing the syntax, but I could
not find such a explanation. My apologies if I oversaw something.
Thanks in advance,
Emilio Pastor Mira
Emilio Pastor Mira
Utimaco IS GmbH
Germanusstr. 4
DE-52080 Aachen
Email: emilio.pastorm...@utimaco.com
Website: hsm.utimaco.com
Utimaco IS GmbH
Seat: Aachen - Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO
Wichtiger Hinweis:
Diese E-Mail kann Betriebs- und Gesch?ftsgeheimnisse oder sonstige vertrauliche
Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich erhalten haben,
ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielf?ltigung oder Weitergabe
der E-Mail ausdr?cklich untersagt. Bitte benachrichtigen Sie uns und vernichten
Sie die E-Mail. Der Absender hat alle erdenklichen Vorsichtsma?nahmen
getroffen, dass die Anlagen dieser E-Mail frei von Computerviren o. ?. sind.
Gleichwohl schlie?en wir die Haftung f?r jeden Schaden aus, der durch
Computerviren o. ?. verursacht wurde, soweit wir nicht vors?tzlich oder grob
fahrl?ssig gehandelt haben. Wir raten Ihnen, dass Sie in jedem Fall Ihre eigene
Virenpr?fung vornehmen, bevor Sie die Anlagen ?ffnen. Vielen Dank.
Important Notice:
The information contained in this email message may be confidential
information. If you are not the intended recipient, any use, interference with,
disclosure or copying of this material is unauthorised and prohibited. Please
inform us immediately and destroy the email. We have taken every reasonable
precaution to ensure that any attachment to this email has been swept for
viruses. However, we cannot accept liability for any damage sustained as a
result of software viruses and would advise that you carry out your own virus
checks before opening any attachment. Thank you for your cooperation.
bash_bug_report.sh
Description: bash_bug_report.sh
Re: Problem with small script
> On Thu, Feb 18, 2016 at 11:06:37PM +0700, Robert Parker wrote: > > The script: > > #/bin/bash ^ missing ! here typo in the shebang? > > # testlink.sh > > # must be run as root > > > > file1="$1" > > shift > > mandir=/usr/local/share/man/man3/ > > cp "$file1" "$mandir" > > cd "$mandir" > > You MUST check the result of cd. If it fails but you continue on, > you will be operating in the wrong place. > > > echo '$hash = '"$#" > > while (( "$#" )); do > > file2="$1" > > ln "$file1" "$file2" > > shift > > done > > > > Results: > > >> sudo ./testlink.sh readfile.3 readtextfile.3 > > $hash = 1 > > ./testlink.sh: 11: ./testlink.sh: 1: not found > > >> > > As near as I can tell, you are somehow running this script under sh > instead of bash. ciao gabriele
Re: Bug with declarative arrays
On 2/18/16 11:39 AM, Emilio PastorMira wrote:
> The bug I found is related to the possibility of obtaining all keys of a
> declarative array at once (${!ARRAY[@]} syntax). It seems that every time
> such a call is done there is memory allocation, which is NOT deallocated
> when the corresponding scope ends. This produces a memory leak.
Thanks for the report. The fix was easy and will be in the next version
of bash.
I've attached a patch if you'd like to play around with it. Your line
numbers will certainly vary.
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/
*** ../bash-4.3-patched/subst.c 2015-08-13 15:11:52.0 -0400
--- subst.c 2016-02-18 13:57:34.0 -0500
***
*** 7353,7356
--- 8041,8045
}
+ free (name);
free (temp1);
*indexp = sindex;
Re: Add a mirror to github
On 2/18/16 1:10 AM, konsolebox wrote: > On Tue, Feb 16, 2016 at 4:25 AM, Chet Ramey wrote: >> On 2/14/16 1:41 AM, konsolebox wrote: >>> Hi Chet, >>> >>> Please consider adding a mirror of bash's git repo in github.com. It >>> would be easier for many people in the community to contribute code >>> and discuss it there. >> >> There's nothing stopping people from doing that now, and I'd rather >> discussions take place on this list. > > Well there's no meaning to it unless it's official and that you > participate in talking about the contributed patches and issues people > choose to post in there, but I accept your decision. I have a limited time to read and respond to issues, and I prefer to funnel those through the official mailing list. -- ``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/
ERR trap reset in subshell by unrelated trap
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-pc-linux-gnu' -DCONF_
uname output: Linux debian 4.1.0 #1 SMP Sat Jul 11 10:34:14 CEST 2015 i686
GNU/Linux
Machine Type: i586-pc-linux-gnu
Bash Version: 4.3
Patch Level: 30
Release Status: release
Description:
Setting the errtrace shell option makes subshells inherit the ERR trap
of the parent. This is working fine but the ERR trap is silently reset
in the subshell when another, unrelated signal trap is installed.
Repeat-By:
Execute the following script. The execution should stop in the shell
function at the 'false' command due to the ERR trap and the errtrace
option.
$ cat > test.sh <<'EOF'
#!/bin/bash
set -o errtrace
trap 'echo "ERR trap called at level $BASH_SUBSHELL" ; exit 1' ERR
(
echo "Subshell inherited traps:"
trap
# install unrelated EXIT trap
trap 'echo "Subshell EXIT trap called: $?"' EXIT
echo "Traps after installing additional EXIT trap:"
trap
# should fail but doesn't
false
echo "SHOULD NOT BE REACHED"
)
echo "SHOULD NOT BE REACHED EITHER"
EOF
$ bash ./test.sh
Subshell inherited traps:
trap -- 'echo "ERR trap called at level $BASH_SUBSHELL" ; exit 1' ERR
Traps after installing additional EXIT trap:
trap -- 'echo "Subshell EXIT trap called: $?"' EXIT
SHOULD NOT BE REACHED
Subshell EXIT trap called: 0
SHOULD NOT BE REACHED EITHER
This bug is still present in the latest version:
$ ./bash --version
GNU bash, version 4.4.0(4)-beta (i686-pc-linux-gnu)
Fix:
The culprit seems to be free_trap_strings(). This function is invoked in
a subshell to cleanup allocated strings. *But* it purges the shell
special traps (DEBUG, ERR, RETURN) too, even though they were left in
place by reset_or_restore_signal_handlers() if the right options were
set.
The following patch fixes the problem but I'm not sure if this is
correct. At least the test case is working then as expected:
$ ./bash ./test.sh
Subshell inherited traps:
trap -- 'echo "ERR trap called at level $BASH_SUBSHELL" ; exit 1' ERR
Traps after installing additional EXIT trap:
trap -- 'echo "Subshell EXIT trap called: $?"' EXIT
trap -- 'echo "ERR trap called at level $BASH_SUBSHELL" ; exit 1' ERR
ERR trap called at level 1
Subshell EXIT trap called: 1
ERR trap called at level 0
Regards,
Jan
--- trap.c.orig 2015-09-26 16:39:31.0 +0200
+++ trap.c 2016-02-18 21:30:01.116852477 +0100
@@ -1140,12 +1140,31 @@
{
register int i;
- for (i = 0; i < BASH_NSIG; i++)
+ for (i = 0; i < NSIG; i++)
{
if (trap_list[i] != (char *)IGNORE_SIG)
free_trap_string (i);
}
- trap_list[DEBUG_TRAP] = trap_list[EXIT_TRAP] = trap_list[ERROR_TRAP] =
trap_list[RETURN_TRAP] = (char *)NULL;
+
+ if (trap_list[EXIT_TRAP])
+free_trap_string (EXIT_TRAP);
+ trap_list[EXIT_TRAP] = (char *)NULL;
+
+ if (function_trace_mode == 0)
+{
+ if (trap_list[DEBUG_TRAP])
+ free_trap_string (DEBUG_TRAP);
+ if (trap_list[RETURN_TRAP])
+ free_trap_string (RETURN_TRAP);
+ trap_list[DEBUG_TRAP] = trap_list[RETURN_TRAP] = (char *)NULL;
+}
+
+ if (error_trace_mode == 0)
+{
+ if (trap_list[ERROR_TRAP])
+ free_trap_string (ERROR_TRAP);
+ trap_list[ERROR_TRAP] = (char *)NULL;
+}
}
/* Free a trap command string associated with SIG without changing signal
