parallel several jobs in bash
Hi, I wonder how to in a bash script(or other languages if more convenient and/or fast) manage independent jobs(executables with command line arguments) and make them run in parallel? Is there a way to create several sub-process without waiting them to finish? Which one is faster: multi-threading or multi-process? Thanks and regards!
Re: Parallelization of shell scripts for 'configure' etc.
Hi all, On 14.06.22 00:39, Paul Eggert wrote: In many Gnu projects, the 'configure' script is the biggest barrier to building because it takes s long to run. Is there some way that we could improve its performance without completely reengineering it, by improving Bash so that it can parallelize 'configure' scripts? A faster configure script execution indeed is something I'd love to see. The title of this thread infers that we *only* want to discuss parallelization - maybe we can generalize this to "Making configure scripts run faster" ? [A little side-note: the invocation of gnulib-tool is *far* slower than the running the configure scripts, for the projects that I work on. But surely this is a problem on it own.] I see two main setups when running configure scripts. How to speeding up the execution has several possible solutions for each of the setups (but with overlaps of course). a) The maintainer/contributor/hacker setup This is when you re-run configure relatively often for the same project(s). I do this normally and and came up with https://gitlab.com/gnuwget/wget2/-/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain. It may be a bit outdated, but may help one or the other here. Btw, I am down to 2.5s for a ./configure run from 25s originally. b) The one-time build setup This is people building + installing from tarball and automated build systems (e.g. CI) with regular OS updates. I also think of systems like Gentoo where you build everything from source. As Alex Ameen pointed out, using a global configure cache across different projects may be insecure. Also people often want to use optimization in this case. Installing ccache is also not likely when people just want to build+install a single project. I personally see a) as solved, at least for me. b) is a problem because 1. People start to complain about the slow GNU build system (autotools), which drives new projects away from using autotools and possible it drives people away from GNU in general. Or in other words: let's not eat up people's precious time unnecessarily when building our software. 2. Building software in large scale eats tons of energy. If we could reduce the energy consumption, it gives us at least a better feeling. What can we do to solve b) I guess we first need to analyze/profile the configure execution. For this I wrote a little tool some years ago: https://gitlab.com/rockdaboot/librusage. It's simple to build and use and gives some number of which (external) commands are executed - fork+exec are pretty heavy. [Configure for wget2 runs 'rm' and 'cat' each roughly 2000x - so I came up with enabling plugins for those two commands (had to write a plugin for 'rm', not sure if it never has been accepted by bash upstream).] Maybe be we can create plugins for other highly used commands as well e.g. for sed !? The output of the tool also roughly allows to see where the time goes - it's beyond my spare time to go deeper into this right now. Please test yourself and share some numbers. Another option is to group tests, e.g. if test 1 is X, we also know the results for tests 2,3,4,... Or we group several tests into a single C file, if possible. Just an idea (sounds a bit tedious, though). Parallelism... can't we do that with &, at least for well-known / often-used tests ? Family calls... Regards, Tim OpenPGP_signature Description: OpenPGP digital signature
interactive test faulty
Bash version 4.1.7(2) Slackware 13.1.0 (32bit) (2.6.33.4-smp kernel, i686 AMD Athlon II X2 250 processor) $- does not work as documented example, from a bash shell *echo e"$-"* output is *ehimBH* put echo "$-" in a oneline bash script called test and make executable *./test* output is *ehB* this should include the "i" in the output as the shell _is_ interactive *echo hi|./test * output is *e* this is as expected input is not from a tty either the functionality of bash is not correct or the meaning of interactive is not clear. eg a script called test2 as follows #!/bin/bash echo "type in your name" read USERNAME echo "hello $USERNAME" called via the shell by typing ./test2 is interactive, but $- special variable doe not indicate it is. regards, Tim
How to initialize a read-only, global, associative array in Bash?
Hi folks,
I execute the following code in Bash version "GNU bash, Version
4.2.39(1)-release (x86_64-redhat-linux-gnu)":
function foobar {
declare -rgA FOOBAR=([foo]=bar)
}
foobar
declare -p FOOBAR
# Output: declare -Ar FOOBAR='()'
Why doesn't Bash initialize FOOBAR with ([foo]=bar) according to
declare -p? The same declaration works outside of a function, e.g.
declare -rgA FOOBAR=([foo]=bar)
declare -p FOOBAR
# Output: declare -Ar FOOBAR='([foo]="bar" )'
Similarly the following code but without FOOBAR being read-only works:
function foobar {
declare -gA FOOBAR
FOOBAR=([foo]=bar)
}
foobar
declare -p FOOBAR
# Output: declare -A FOOBAR='([foo]="bar" )'
Is this a bug or feature?
Cheers,
Tim
BTW: I couldn't find a "bashbug" RPM package in the Fedora 17
repositories; that's why I wrote this formless mail. Sorry for that.
--
`°<
C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC
Why is not every variable initialized to its data type specific default value upon declaration in Bash?
Hi folks, when I execute the following code in Bash version "GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)", I get: declare a declare -p a # Output: -bash: declare: a: not found declare -i b declare -p b # Output: -bash: declare: b: not found declare -a c declare -p c # Output: declare -a c='()' declare -A d declare -p d # Output: declare -A d='()' Arguably I think that the above variables should either be initialized in all cases or in none of them. That would seem more consistent rather than initializing only arrays upon declaration. Cheers, Tim -- `°< C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC
How to presence-detect an array variable or subscript thereof with `test -v`?
Hi folks, I came accross the `-v` option of the `test` command and wondered how I would possibly test not only string- and integer- but also array variables as a whole and in parts. I thought it should be possible to say: declare -Ai foobar=([bar]=0) test -v foobar[foo] && echo true || echo false # Output: true test -v foobar[bar] && echo true || echo false # Output: true Even quoting doesn't help here except for the opposite results: test -v "foobar[foo]" && echo true || echo false # Output: false test -v "foobar[bar]" && echo true || echo false # Output: false Obviously the results should be "false" and "true", respectively. Apart from arrays everything else works as follows: test -v a && echo true || echo false # Output: false declare a="" test -v a && echo true || echo false # Output: true test -v b && echo true || echo false # Output: false declare -i b=0 test -v b && echo true || echo false # Output: true test -v c && echo true || echo false # Output: false declare -a c=() test -v c && echo true || echo false # Output: true Cheers, Tim -- -- `°< C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC
Strange re-initialization of array. Bug or feature?
Hi folks,
I execute the following code with Bash version "GNU bash, Version
4.2.39(1)-release (x86_64-redhat-linux-gnu)" on Fedora 17:
# Returns 0 else 1 if the sourcing (source) script isn't keyed by its base
name in the global "ONCE" array yet.
#
# A script should include this script near the top with "source me_once ||
return 0" in order to get sourced itself only
# once.
#
# @return 0 on success, n != 0 on failure.
#
function me_once {
unset -f me_once
if [[ ! -v ONCE ]]; then
echo AAA
declare -gAi ONCE=()
fi
echo BBB
declare -p ONCE
declare -r a="${BASH_SOURCE[2]##*/}"
if (( ${ONCE[$a]:+1} )); then
return 1
else
ONCE+=(["$a"]=1)
echo CCC
declare -p ONCE
fi
}
me_once
If sourced at least twice from another script I get the following output
printed:
AAA
BBB
declare -A ONCE='()'
CCC
declare -A ONCE='([std.bash]="1" )'
BBB
declare -Ai ONCE='()'
CCC
declare -Ai ONCE='([std.bash]="1" )'
If I remove the initialization "=()" from "declare -gAi ONCE" I get the
following output printed:
AAA
BBB
declare -Ai ONCE='()'
CCC
declare -Ai ONCE='([std.bash]="1" )'
BBB
declare -Ai ONCE='([std.bash]="1" )'
The "declare -gAi ONCE=()" seems to get executed every time although
surrounded by "[[ ! -v ONCE ]]" whereas "echo AAA" within the same if-block
only the first time.
Is this a bug or feature?
Cheers,
Tim
--
--
`°<
C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC
Why can't I say "&>&3"? Bug or feature?
Hi folks, why is it that I can't say: exec 3>/dev/null echo foobar &>&3 # Error: "-bash: syntax error near unexpected token `&'" but the following works: echo foobar &>/dev/null echo foobar >&3 2>&3 I think the succinct notation "&>&N" where N is some numbered file descriptor should work also. Is this behavior a bug or feature? Cheers, Tim -- `°< C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC
Bash's declare -p HISTIGNORE brings bash to a halt! Why?
Hi, executing the following code in GNU bash, Version 4.2.45(1)-release (x86_64-redhat-linux-gnu), Fedora 19 ... shopt -s extglob export HISTIGNORE="!(+(!([[\:space\:]]))+([[\:space\:]])+(!([[\:space\:]])))" declare -p HISTIGNORE ... brings bash to a full stop. It does not print a command prompt hereafter. Why is that. Background: All I want to tell bash is to ignore any simple, i.e. one word command. Bash should not remember command lines like `cd`, `pwd`, `history`, etc. My original definition of the `HISTIGNORE` variable looked like this: export HISTIGNORE="!(+(!([[:space:]]))+([[:space:]])+(!([[:space:]])))" I added a `\` backslash character before each `:` colon character because according to the `bash` info pages the latter separates each (extended) shell glob, i.e. pattern from another. Without escaping the single pattern does not have any effect and a simple command still makes it into history. Cheers Tim
Re: Bash's declare -p HISTIGNORE brings bash to a halt! Why?
Hi Chet, hmm ... I simplified the pattern to "+([^[:space:]])". It works on when I let bash expand files but it does not keep bash from adding "word" commands such as "cd", "pwd", etc. My history related settings are as follows: shopt -s extglob declare -x HISTSIZE="1" declare -x HISTFILESIZE="1" declare -x histchars="!^#" declare -x HISTIGNORE="+([^[:space:]])" declare -x HISTCONTROL="ignorespace:ignoredups:erasedups" declare -x HISTTIMEFORMAT="%FT%T " declare -x HISTFILE="/home/tifr/.cache/bash/history" Any ideas as to how to correctly assign the "+([^[:space:]])" pattern to the "HISTIGNORE" variable? By the way I'm setting the history related variables from my ".bash_login" file. That is why I'm exporting them. Thank you very much for your help. Kind regards Tim 2014/1/11 Tim Friske : > Hi, > > executing the following code in GNU bash, Version 4.2.45(1)-release > (x86_64-redhat-linux-gnu), Fedora 19 ... > > shopt -s extglob > export > HISTIGNORE="!(+(!([[\:space\:]]))+([[\:space\:]])+(!([[\:space\:]])))" > declare -p HISTIGNORE > > ... brings bash to a full stop. It does not print a command prompt > hereafter. Why is that. > > Background: > > All I want to tell bash is to ignore any simple, i.e. one word > command. Bash should not remember command lines like `cd`, `pwd`, > `history`, etc. My original definition of the `HISTIGNORE` variable > looked like this: > > export HISTIGNORE="!(+(!([[:space:]]))+([[:space:]])+(!([[:space:]])))" > > I added a `\` backslash character before each `:` colon character > because according to the `bash` info pages the latter separates each > (extended) shell glob, i.e. pattern from another. Without escaping the > single pattern does not have any effect and a simple command still > makes it into history. > > Cheers > Tim
Re: Bash's declare -p HISTIGNORE brings bash to a halt! Why?
Hi Chet, apparently bash does not recognize the ":" colon characters in POSIX character classes when assigned to the "HISTIGNORE" variable. I tried to set the "HISTIGNORE" variable directly from within a non-login, interactive session. But still I cannot convince bash's history with the following definitions: 1.) HISTIGNORE="+([[:word:]])" 2.) HISTIGNORE="+([^[:space:]])" On the other hand such simple definitions work: 1.) HISTIGNORE="+([a-z])" 2.) HISTIGNORE="+([-0-9A-Z_a-z])" Best regards Tim 2014/1/12 Tim Friske : > Hi Chet, > > hmm ... I simplified the pattern to "+([^[:space:]])". It works on > when I let bash expand files but it does not keep bash from adding > "word" commands such as "cd", "pwd", etc. My history related settings > are as follows: > > shopt -s extglob > > declare -x HISTSIZE="1" > declare -x HISTFILESIZE="1" > declare -x histchars="!^#" > declare -x HISTIGNORE="+([^[:space:]])" > declare -x HISTCONTROL="ignorespace:ignoredups:erasedups" > declare -x HISTTIMEFORMAT="%FT%T " > declare -x HISTFILE="/home/tifr/.cache/bash/history" > > Any ideas as to how to correctly assign the "+([^[:space:]])" pattern > to the "HISTIGNORE" variable? By the way I'm setting the history > related variables from my ".bash_login" file. That is why I'm > exporting them. > > Thank you very much for your help. > > Kind regards > Tim > > 2014/1/11 Tim Friske : >> Hi, >> >> executing the following code in GNU bash, Version 4.2.45(1)-release >> (x86_64-redhat-linux-gnu), Fedora 19 ... >> >> shopt -s extglob >> export >> HISTIGNORE="!(+(!([[\:space\:]]))+([[\:space\:]])+(!([[\:space\:]])))" >> declare -p HISTIGNORE >> >> ... brings bash to a full stop. It does not print a command prompt >> hereafter. Why is that. >> >> Background: >> >> All I want to tell bash is to ignore any simple, i.e. one word >> command. Bash should not remember command lines like `cd`, `pwd`, >> `history`, etc. My original definition of the `HISTIGNORE` variable >> looked like this: >> >> export HISTIGNORE="!(+(!([[:space:]]))+([[:space:]])+(!([[:space:]])))" >> >> I added a `\` backslash character before each `:` colon character >> because according to the `bash` info pages the latter separates each >> (extended) shell glob, i.e. pattern from another. Without escaping the >> single pattern does not have any effect and a simple command still >> makes it into history. >> >> Cheers >> Tim
Possible bug when combining Bash's process substitution with HERE-document?
Hi, see my question http://unix.stackexchange.com/questions/137506/how-to-combine-bashs-process-substitution-with-here-document for a description. Could the described behavior be a bug? Kind regards Tim
Re: Possible bug when combining Bash's process substitution with HERE-document?
Hi, first I want to thank you for your help. While searching for an alternative I came up with the following code which does not work when I have the "shopt -os errexit" command line at the top of my script: read -d '' -r foobar <: > On 6/18/14, 4:27 PM, Dan Douglas wrote: >> On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey wrote: >>> Yes, since bash can parse the same construct without any problems if you >>> use command substitution, it looks like a bug. I'll take a look. >> >> It brings to mind all those unbalanced paren case..esac bugs that >> affected every shell ever. >> I suppose this might qualify as a bug too? > > Yes, with the same fix. > > 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/
Bug or feature: Why does Bash's "printf" define global variables?
Hi,
my assumption was that Bash's "printf" builtin implicitly defines a local
variable when used inside a function like so:
function foobar { printf -v foo bar; }
foobar
declare -p foo
# Prints "bar" from the global "foo" variable.
But instead I have to declare the "foo" variable to be a "local" member of
the "foobar" function like so:
unset -v foo
function foobar { local foo=; printf -v foo bar; }
foobar
declare -p foo
# Prints an error message saying that there is no "foo" defined.
Cheers
Tim
Feature request: Add "import" built-in.
Hi,
as I see it the "source" built-in is perfect for embedding a sourced
Bash script into the sourcing one while preserving as much of the
environment, specifically the positional and special parameters, as
possible.
What I am missing is the "import" built-in that passes only the
explicitly given arguments from the importing to the imported Bash script.
I currently emulate the behavior I seek for with the following function:
function _import {
local -r file="$1"
set -- "${@:2}"
source "$file" "$@"
}
For details please see my question and the answers on Unix & Linux
Exchange [1].
[1]
http://unix.stackexchange.com/questions/151889/why-does-bashs-source-command-behave-differently-when-called-from-a-function
Cheers
Tim
signature.asc
Description: OpenPGP digital signature
incorrect 'LC_ALL=C export LC_ALL' behavour
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables uname output: Linux gene.surrey.redhat.com 2.6.12-1.1432_FC5 #1 Wed Jul 13 03:12:36 EDT 2005 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.0 Patch Level: 16 Release Status: release Description: See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165249 This script gives incorrect output when run against correct locale data: rm -rf arena mkdir arena cd arena touch a B c LC_ALL=en_US.UTF-8 LC_ALL=C export LC_ALL echo [a-c] The expected output is 'a c', but the actual output includes 'B'. Although the LC_ALL variable has been set, the setlocale() function was not called to update the locale. Repeat-By: See above. Fix: --- bash-3.0/builtins/setattr.def.setlocale 2005-08-08 12:22:42.0 +0100 +++ bash-3.0/builtins/setattr.def 2005-08-08 12:25:16.0 +0100 @@ -423,4 +423,7 @@ if (var && (exported_p (var) || (attribute & att_exported))) array_needs_making++; /* XXX */ + + if (var) +stupidly_hack_special_variables (name); } ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Makefile.in patch
Version 3.0 patch level 16
The PATH in the tests target was causing the (incompatible in this case)
system printenv to be used instead of the one in the tests dir.
The run-func and run-varenv tests would fail without this patch.
Errors looked like
.
16d15
< UX:env: ERROR: No such file or directory: AVAR
18c17
< UX:env: ERROR: No such file or directory: AVAR
---
> foo
.....
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
--- bash-3.0/Makefile.in.old 2004-03-17 05:34:39.0 -0800
+++ bash-3.0/Makefile.in 2005-09-16 16:51:18.284178088 -0700
@@ -792,7 +792,7 @@
@-test -d tests || mkdir tests
@cp $(TESTS_SUPPORT) tests
@( cd $(srcdir)/tests && \
- PATH=$$PATH:$(BUILD_DIR)/tests THIS_SH=$(THIS_SH) $(SHELL) ${TESTSCRIPT} )
+ PATH=$(BUILD_DIR)/tests:$$PATH THIS_SH=$(THIS_SH) $(SHELL) ${TESTSCRIPT} )
symlinks:
$(SHELL) $(SUPPORT_SRC)fixlinks -s $(srcdir)
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
[patch] unsafe signal handler
Hi,
Here is a patch which aims to address the problem reported earlier:
http://lists.gnu.org/archive/html/bug-bash/2005-07/msg00129.html
by making the signal handler set a flag which is then checked at
strategic points in the main flow of code.
What do you think?
Tim.
*/
--- bash-3.0/sig.c.sighandler 2005-12-06 16:55:26.0 +
+++ bash-3.0/sig.c 2005-12-06 17:14:29.0 +
@@ -58,6 +58,8 @@
extern int loop_level, continuing, breaking;
extern int parse_and_execute_level, shell_initialized;
+int need_termination_unwind_protect = 0;
+
/* Non-zero after SIGINT. */
int interrupt_state;
@@ -408,6 +410,13 @@
termination_unwind_protect (sig)
int sig;
{
+ need_termination_unwind_protect = sig;
+ SIGRETURN (0);
+}
+
+void
+do_termination_unwind_protect (int sig)
+{
if (sig == SIGINT && signal_is_trapped (SIGINT))
run_interrupt_trap ();
@@ -429,8 +438,6 @@
run_exit_trap ();
set_signal_handler (sig, SIG_DFL);
kill (getpid (), sig);
-
- SIGRETURN (0);
}
/* What we really do when SIGINT occurs. */
--- bash-3.0/sig.h.sighandler 2005-12-06 17:00:22.0 +
+++ bash-3.0/sig.h 2005-12-06 17:17:32.0 +
@@ -109,8 +109,12 @@
#endif /* JOB_CONTROL */
+/* Global variables from sig.c */
+extern int need_termination_unwind_protect;
+
/* Functions from sig.c. */
extern sighandler termination_unwind_protect __P((int));
+extern void do_termination_unwind_protect __P((int));
extern sighandler sigint_sighandler __P((int));
extern void initialize_signals __P((int));
extern void initialize_terminating_signals __P((void));
@@ -123,4 +127,11 @@
extern SigHandler *trap_to_sighandler __P((int));
extern sighandler trap_handler __P((int));
+#define CATCH_SIGNALS()
\
+ do \
+{ \
+ if (need_termination_unwind_protect) \
+ do_termination_unwind_protect (need_termination_unwind_protect); \
+} while (0)
+
#endif /* _SIG_H_ */
--- bash-3.0/input.c.sighandler 2005-12-06 17:19:59.0 +
+++ bash-3.0/input.c2005-12-06 17:27:04.0 +
@@ -41,6 +41,7 @@
#include "input.h"
#include "error.h"
#include "externs.h"
+#include "sig.h"
#if !defined (errno)
extern int errno;
@@ -66,6 +67,7 @@
{
while (1)
{
+ CATCH_SIGNALS ();
local_bufused = read (fileno (stream), localbuf, sizeof(localbuf));
if (local_bufused > 0)
break;
--- bash-3.0/jobs.c.sighandler 2005-12-06 17:22:46.0 +
+++ bash-3.0/jobs.c 2005-12-06 17:26:06.0 +
@@ -2513,6 +2513,7 @@
retry:
if (wcontinued_not_supported)
waitpid_flags &= ~WCONTINUED;
+ CATCH_SIGNALS ();
pid = WAITPID (-1, &status, waitpid_flags);
if (pid == -1 && errno == EINVAL)
{
@@ -2537,6 +2538,7 @@
/* If waitpid returns 0, there are running children. If it returns -1,
the only other error POSIX says it can return is EINTR. */
+ CATCH_SIGNALS ();
if (pid <= 0)
continue; /* jumps right to the test */
--- bash-3.0/execute_cmd.c.sighandler 2005-12-07 11:26:31.0 +
+++ bash-3.0/execute_cmd.c 2005-12-07 11:27:28.0 +
@@ -360,6 +360,7 @@
unlink_fifo_list ();
#endif /* PROCESS_SUBSTITUTION */
+ CATCH_SIGNALS ();
return (result);
}
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
[patch] memory leak in read builtin
There is at least one memory leak in the read builtin in bash-3.0. To
demonstrate it, try this test case:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173283#c10
There is a link to a file, nonblock.c, which you should compile like
'make nonblock'. Then run the short script to see the problem.
The problem comes about when stdin has O_NONBLOCK set. Here is the
fix:
--- bash-3.0/builtins/read.def.read-memleak 2005-12-07 17:45:38.0
+
+++ bash-3.0/builtins/read.def 2005-12-07 17:45:39.0 +
@@ -461,6 +461,7 @@
if (retval < 0)
{
builtin_error (_("read error: %d: %s"), fd, strerror (errno));
+ run_unwind_frame ("read_builtin");
return (EXECUTION_FAILURE);
}
#endif
There is another suspicious place in that function where an xfree is
notable by its absence:
--- bash-3.0/builtins/read.def.read-memleak 2005-12-07 17:45:38.0
+
+++ bash-3.0/builtins/read.def 2005-12-07 18:00:26.0 +
@@ -508,7 +508,10 @@
var = find_or_make_array_variable (arrayname, 1);
if (var == 0)
- return EXECUTION_FAILURE; /* readonly or noassign */
+ {
+ xfree (input_string);
+ return EXECUTION_FAILURE; /* readonly or noassign */
+ }
array_flush (array_cell (var));
alist = list_string (input_string, ifs_chars, 0);
..but I couldn't work out how to demonstrate this particular leak, if
that's what it is.
Tim.
*/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Incorrect completion when quoting last component of path
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables uname output: Linux gene.surrey.redhat.com 2.6.13-1.1597_FC5 #1 Thu Oct 6 02:13:06 EDT 2005 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.1 Patch Level: 1 Release Status: release Description: Tab completion is wrong when completing a file path if the last component is quoted. Repeat-By: rm -rf arena mkdir arena cd arena mkdir d touch d/f ls d/' Results: ls: d/d/f: No such file or directory Original report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176790 Tim. */ pgpoZ0Tgc9hUK.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [patch] Re: Job-handling bug in bash-3.0 and bash-2.05b
On Mon, Mar 21, 2005 at 03:29:24PM -0500, Chet Ramey wrote: > > This job-handling bug is still present. Chet, would you mind > > commenting on it? > > It will be fixed in bash-3.1. It isn't. The symptom has changed, however: bash now segfaults. #0 0x0807722c in find_last_proc (job=1243, block=0) at jobs.c:1917 1917 while (p->next != jobs[job]->pipe) (gdb) bt #0 0x0807722c in find_last_proc (job=1243, block=0) at jobs.c:1917 #1 0x0807976a in delete_job (job_index=1243, warn_stopped=0) at jobs.c:911 #2 0x08079bd4 in cleanup_dead_jobs () at jobs.c:817 #3 0x0806e3fc in execute_while_or_until (while_command=0x8d13468, type=0) at execute_cmd.c:2302 #4 0x0806cefc in execute_command_internal (command=0x8d2dab0, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x8d13478) at execute_cmd.c:2269 #5 0x0806e2f7 in execute_command (command=0x8d2dab0) at execute_cmd.c:354 #6 0x0805e7f6 in reader_loop () at eval.c:147 #7 0x0805e275 in main (argc=1, argv=0xbfbefa44, env=0xbfbefa54) at shell.c:724 Tim. */ pgp0QK5EtNzl9.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
[patch] 3.1: man page corrections
When viewing the bash man page with 'man bash' in a locale that
supports UTF-8 (for example), the single-quote character "'" doesn't
necessarily display as we want. For a literal single-quote character,
"\(aq" is needed in the groff input.
Original bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177051
This patch is necessary in order to enable cut-and-pasting of examples
etc.
Tim.
*/
--- bash-3.1/doc/bash.1.aq 2006-01-06 16:40:40.0 +
+++ bash-3.1/doc/bash.1 2006-01-06 16:46:36.0 +
@@ -977,7 +977,7 @@
.B PARAMETERS
below).
.PP
-Words of the form \fB$\fP'\fIstring\fP' are treated specially. The
+Words of the form \fB$\fP\(aq\fIstring\fP\(aq are treated specially. The
word expands to \fIstring\fP, with backslash-escaped characters replaced
as specified by the ANSI C standard. Backslash escape sequences, if
present, are decoded as follows:
@@ -1011,7 +1011,7 @@
.B \e\e
backslash
.TP
-.B \e'
+.B \e\(aq
single quote
.TP
.B \e\fInnn\fP
@@ -1845,7 +1845,7 @@
Example:
.RS
.PP
-\fBMAILPATH\fP='/var/mail/bfox?"You have mail":~/shell\-mail?"$_ has mail!"'
+\fBMAILPATH\fP=\(aq/var/mail/bfox?"You have mail":~/shell\-mail?"$_ has
mail!"\(aq
.PP
.B Bash
supplies a default value for this variable, but the location of the user
@@ -1979,7 +1979,7 @@
included.
.IP
If this variable is not set, \fBbash\fP acts as if it had the
-value \fB$'\enreal\et%3lR\enuser\et%3lU\ensys\t%3lS'\fP.
+value \fB$\(aq\enreal\et%3lR\enuser\et%3lU\ensys\t%3lS\(aq\fP.
If the value is null, no timing information is displayed.
A trailing newline is added when the format string is displayed.
.TP
@@ -2708,7 +2708,7 @@
.B IFS
is null, no word splitting occurs.
.PP
-Explicit null arguments (\^\f3"\^"\fP or \^\f3'\^'\fP\^) are retained.
+Explicit null arguments (\^\f3"\^"\fP or \^\f3\(aq\^\(aq\fP\^) are retained.
Unquoted implicit null arguments, resulting from the expansion of
parameters that have no values, are removed.
If a parameter with no value is expanded within double quotes, a
@@ -2930,7 +2930,7 @@
After the preceding expansions, all unquoted occurrences of the
characters
.BR \e ,
-.BR ' ,
+.BR \(aq ,
and \^\f3"\fP\^ that did not result from one of the above
expansions are removed.
.SH REDIRECTION
@@ -4495,8 +4495,8 @@
.B \e"
literal "
.TP
-.B \e'
-literal '
+.B \e\(aq
+literal \(aq
.RE
.PD
.PP
@@ -4544,7 +4544,7 @@
Unquoted text is assumed to be a function name.
In the macro body, the backslash escapes described above are expanded.
Backslash will quote any other character in the macro text,
-including " and '.
+including " and \(aq.
.PP
.B Bash
allows the current readline key bindings to be displayed or modified
@@ -7320,7 +7320,7 @@
In addition to the standard \fIprintf\fP(1) formats, \fB%b\fP causes
\fBprintf\fP to expand backslash escape sequences in the corresponding
\fIargument\fP (except that \fB\ec\fP terminates output, backslashes in
-\fB\e'\fP, \fB\e"\fP, and \fB\e?\fP are not removed, and octal escapes
+\fB\e\(aq\fP, \fB\e"\fP, and \fB\e?\fP are not removed, and octal escapes
beginning with \fB\e0\fP may contain up to four digits),
and \fB%q\fP causes \fBprintf\fP to output the corresponding
\fIargument\fP in a format that can be reused as shell input.
@@ -8037,7 +8037,7 @@
\fBPathname Expansion\fP are enabled.
.TP 8
.B extquote
-If set, \fB$\fP'\fIstring\fP' and \fB$\fP"\fIstring\fP" quoting is
+If set, \fB$\fP\(aq\fIstring\fP\(aq and \fB$\fP"\fIstring\fP" quoting is
performed within \fB${\fP\fIparameter\fP\fB}\fP expansions
enclosed in double quotes. This option is enabled by default.
.TP 8
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
"echo: write error: Broken pipe" even when DONT_REPORT_SIGPIPE set
Comparing bash-3.0 (with config-top.h modified so that DONT_REPORT_SIGPIPE is defined) with bash-3.1 (where this is the default anyway) shows up a change in behaviour. bash-3.0: $ bash -c 'trap exit SIGPIPE; echo foo' | : $ bash-3.1: $ bash -c 'trap exit SIGPIPE; echo foo' | : bash: line 0: echo: write error: Broken pipe $ Is this change in behaviour intentional, or a regression? Original bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177242 Thanks, Tim. */ pgprpHnWZKsa0.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: "echo: write error: Broken pipe" even when DONT_REPORT_SIGPIPE set
On Mon, Jan 09, 2006 at 02:22:11PM -0500, Chet Ramey wrote: > > bash-3.1: > > > > $ bash -c 'trap exit SIGPIPE; echo foo' | : > > bash: line 0: echo: write error: Broken pipe > > $ > > > > Is this change in behaviour intentional, or a regression? > > It's intentional, and doesn't have anything to do with job control > or processes dying from SIGPIPE in general. There were several bug > reports filed against bash-3.0 complaining that the only way to > check whether or not echo failed to write requested data was to use > the exit status. (Mostly in connection with redirected output on a > full or unavailable file system.) `echo' now displays an error > message on write errors. `printf' does the same thing. If there is no trap set it doesn't report an error. So is this special behaviour only triggered when there is a trap for SIGPIPE in place? GNU bash, version 3.1.1(1)-release (i386-redhat-linux-gnu) $ bash -c 'echo foo' | : $ Tim. */ pgpyKiTvIcqaN.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
[patch] fix 'exec -l /bin/bash'
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4
-fasynchronous-unwind-tables
uname output: Linux gene.surrey.redhat.com 2.6.13-1.1597_FC5 #1 Thu Oct 6
02:13:06 EDT 2005 i686 i686 i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu
Bash Version: 3.1
Patch Level: 1
Release Status: release
Description:
If bash has argv[0] as '-/bin/bash' it does not become a login
shell.
Repeat-By:
exec -l /bin/bash
shopt
Fix:
--- bash-3.1/shell.c.login 2006-01-13 16:52:14.0 +
+++ bash-3.1/shell.c2006-01-13 16:52:15.0 +
@@ -1543,9 +1543,10 @@
any startup files; just try to be more like /bin/sh. */
shell_name = argv0 ? base_pathname (argv0) : PROGRAM;
- if (*shell_name == '-')
+ if (argv0 && *argv0 == '-')
{
- shell_name++;
+ if (*shell_name == '-')
+shell_name++;
login_shell++;
}
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
inputrc parsing regression?
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables uname output: Linux gene.surrey.redhat.com 2.6.13-1.1597_FC5 #1 Thu Oct 6 02:13:06 EDT 2005 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.1 Patch Level: 5 Release Status: release Description: In bash-3.0 the following inputrc assigned functions to arrow-up and arrow-down: set meta-flag on set input-meta on set convert-meta off set output-meta on "\M-[A": history-search-backward "\M-[B": history-search-forward These are the key sequences given by 'bind -p' for those keys. In bash-3.1 this no longer works: bind -p gives eight-bit-set key sequences, and the newly mapped functions are not called. Repeat-By: Set /etc/inputrc as above. Run 'ls'. Run 'cat /etc/inputrc'. Type 'l' and press arrow-up. Should get 'ls' but instead get 'cat /etc/inputrc'. Original bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177808 pgpWik0MCFqm5.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: inputrc parsing regression?
On Tue, Jan 17, 2006 at 05:08:35PM -0500, Chet Ramey wrote: > Before bash-3.1/readline-5.1, key binding did not honor the setting of > convert-meta. The current version treats a key binding exactly the way > readline will when reading a key sequence and dispatching on it, > converting to eight-bit characters as necessary depending on the value > of convert-meta. > > Ironically, you were the one who filed the original bug report that > prompted this change. ;-) Heh :-) Does this mean that you can't just use the key sequences that 'bind -p' displays for rebinding in inputrc? For this particular case I guess '\e[A'/'\e[B' is what I need. Tim. */ pgpUVW7RGVWWw.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
incorrect brace expansion
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4
-fasynchronous-unwind-tables
uname output: Linux gene.surrey.redhat.com 2.6.13-1.1597_FC5 #1 Thu Oct 6
02:13:06 EDT 2005 i686 i686 i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu
Bash Version: 3.1
Patch Level: 5
Release Status: release
Description:
This --> a-{b{d,e}}-c <-- gets wrongly expanded. There is one
brace expansion expression there, surrounded by braces not
formating a brace expansion expression.
Repeat-By:
echo a-{b{d,e}}-c
Should get: a-{bd}-c a-{be}-c
but actually get: a-bd-c a-be-c
Original bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179081
Tim.
*/
pgpb65VgLLPb2.pgp
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash-3.1 official patch 7
On Sun, Feb 05, 2006 at 01:38:47PM -0500, Chet Ramey wrote: >BASH PATCH REPORT >= > > Bash-Release: 3.1 > Patch-ID: bash31-007 > > Bug-Reported-by: Tim Waugh <[EMAIL PROTECTED]>, Laird Breyer <[EMAIL > PROTECTED]> > Bug-Reference-ID: <[EMAIL PROTECTED]> This is great -- now the segfaults are gone. Unfortunately, the original job handling bug I reported still remains. Some exit codes are being reported incorrectly when a process uses a PID that bash has seen before. Tim. */ pgpBKVR3rY4Z8.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [patch] memory leak in read builtin
Hi,
I posted two patches for memory leaks in bash-3.0. One of them has
made it into bash-3.1, but the other has not. Here is the missing
one:
On Wed, Dec 07, 2005 at 06:10:07PM +, Tim Waugh wrote:
> There is at least one memory leak in the read builtin in bash-3.0. To
> demonstrate it, try this test case:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173283#c10
>
> There is a link to a file, nonblock.c, which you should compile like
> 'make nonblock'. Then run the short script to see the problem.
>
> The problem comes about when stdin has O_NONBLOCK set. Here is the
> fix:
>
> --- bash-3.0/builtins/read.def.read-memleak 2005-12-07 17:45:38.0
> +
> +++ bash-3.0/builtins/read.def2005-12-07 17:45:39.0 +
> @@ -461,6 +461,7 @@
>if (retval < 0)
> {
>builtin_error (_("read error: %d: %s"), fd, strerror (errno));
> + run_unwind_frame ("read_builtin");
>return (EXECUTION_FAILURE);
> }
> #endif
Tim.
*/
pgpjjvzU2xTEx.pgp
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Function/alias recursion
What is the intended behaviour for this sort of thing?:
$ cat <<"EOF" >trouble
hello ()
{
pwd
}
alias pwd="hello"
EOF
$ source trouble
$ source trouble
$ pwd
The behaviour I've observed with bash-3.2 and several earlier releases
is that bash consumes all available memory and then crashes.
Tim.
*/
signature.asc
Description: This is a digitally signed message part
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Quoting near =~ is inconsistent
Further to this, I am having trouble porting existing scripts to bash-3.2's new style of regex matching. Here is one example that is problematic: I want to use a character class in my regex, but bash seems to get confused by the ':]]' closing the class, and apparently takes it as a ']]' closing the conditional expression. Here is a distilled test case: [[ $line =~ [[:space:]]*(a)?b ]] && echo match || echo no match I used single quotes around the RHS in bash-3.1, which worked very well. How should this be written so as to work with bash-3.2 -- and, of course, still with bash-3.1? Tim. */ signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
On Mon, 2007-01-22 at 08:04 -0800, Bruce Korb wrote:
> There seems to be something else aside from LC_ALL, LC_COLLATE
> and LANG that affects collating sequence. Notice the difference
> between "[a-d]*" and "[a-D]*". Whatever collating sequence is being used
> do select files puts "D" after "d", though the actual sort puts them as being
> equal. Whatever. I've gotten bored now. :)
It's worth noting here that bash's globbing of '[A-Z]*' etc is
definitely different from the system collation sequence (i.e. using
fnmatch() or glob() functions). There is an open bug report about this
here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217359
Demo:
Steps to Reproduce:
1. touch h
2. sh -c 'LC_ALL=en_US; echo [A-Z]'
3. python -c 'from locale import *; import glob; setlocale(LC_ALL,"en_US");
print glob.glob("[A-Z]")'
Tim.
*/
signature.asc
Description: This is a digitally signed message part
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
On Tue, 2007-01-23 at 17:17 +0100, Andreas Schwab wrote: > glibc definitely uses strcoll as well. Most likely python has its own > implementation which gets it wrong. No, really, this is going through glibc's __collseq_table_lookup function. The Python example is just an easy-to-run distilled test case. Try a little C program using glob() or regex matching. Tim. */ signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
On Tue, 2007-01-23 at 14:14 -0500, Chet Ramey wrote: > The portable, standard way to perform character comparison using the > current locale is strcoll(). If I can't get the same results using > strcoll(), glibc is clearly doing something different internally. (And > there is no portable standard way to obtain the current collating sequence. > The best you can do is sort sets of characters like I did.) Character comparision, yes, but that is different to range matching. > strcoll indicates that, in the "en_US" locale, `h' sorts between `A' and > `Z'. In the "C" locale, it does not. This is consistent with the > collating sequences I posted earlier. Here is what Ulrich Drepper has to say on the matter (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217359#c5): "[...] The strcoll result has nothing whatsoever to do with the range match. strcoll uses collation weights, ranges use collation sequence values, completely different concept. Not matching 'h' (note, lowercase) is correct since if you look at the locale definition you'll see that first all lower characters are described and then the uppercase. So h is not in A-Z. H (uppercase) of course is. From all I can see so far it's entirely bash's fault by not implementing globbing correctly. bash really must use the fnmatch code from glibc itself." Tim. */ signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Why bash is not so efficient as cron?
Are the two environments setting different locales perhaps? If the character encoding is UTF-8 there is quite a bit more work that needs to be done compared to the C locale. Tim. */ signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash-3.2 Official Patch 10
On Mon, 2007-03-05 at 17:49 -0500, Chet Ramey wrote:
> The glibc implementation of regcomp/regexec does not allow backslashes to
> escape "ordinary" pattern characters when matching. Bash used backslashes
> to quote all characters when the pattern argument to the [[ special
> command's =~ operator was quoted. This caused the match to fail on Linux
> and other systems using GNU libc.
There still doesn't seem to be a way to write expressions that work in
3.2 and in 3.1. For example, below is an expression that works fine in
3.1. How do I re-write it so that it (a) continues to work with
bash-3.1, and (b) also works with bash-3.2?
{ cat "$file" ; echo ; } | while read line; do
if [[ ! "$line" =~ '^[[:space:]]*(\#.*)?$' ]]; then
/sbin/ip rule del $line
fi
done
In particular, when the whole thing is de-quoted bash-3.1 seems to
require the parentheses to be escaped, while bash-3.2 seems to require
that they are *not* escaped.
Tim.
*/
signature.asc
Description: This is a digitally signed message part
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
with bash 3.2 from source: hashmarks inside backticks cause parse error
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 uname output: Linux grid-ui.physik.uni-wuppertal.de 2.6.9-67.0.4.EL_SFS2.3_0smp #1 SMP Mon Jul 21 13:57:38 CEST 2008 i686 i686 i386 GNU/Linux Machine Type: i686-redhat-linux-gnu Bash Version: 3.2 Patch Level: 0 Release Status: release Description: A script containing some commands including hashmarks inside a backtick operator fails to run correctly. The hashmark(s) seem to be interpreted in a way that treats the rest of the line as comment, causing the closing backtick to be skipped, and finally resulting in a unexpected EOF parse error. This behaviour only occurs using a bash (3.2) I compiled from source on my machine. I reproduced the problem on a 32bit- and on my 64bit-machine. Repeat-By: Execute the following line: $ echo `seq -w 00 05 | sed -e 's# ##g'` The expected output is: 0 1 2 3 4 5 $ In bash compilations showing the described problem, the output is instead: $ echo `seq -w 00 05 | sed -e "s# ##g"` > (the bash is waiting for further input here... press CTRL+D) bash: unexpected EOF while looking for matching ``' bash: syntax error: unexpected end of file $
coproc command doesn't accept NAME arg
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: darwin9.6.0
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -
DCONF_OSTYPE='darwin9.6.0' -DCONF_MACHTYPE='i386-apple-darwin9.6.0' -
DCONF_VENDOR='apple' -DLOCALEDIR='/usr/local/share/locale' -
DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./
include -I./lib -I./lib/intl -I/Users/tim/tmp/bash-4.0/lib/intl -g -O2
uname output: Darwin Pilot.hq.nutricateonline.com 9.6.0 Darwin Kernel
Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/
RELEASE_I386 i386
Machine Type: i386-apple-darwin9.6.0
Bash Version: 4.0
Patch Level: 0
Release Status: release
Description:
Reading the changelog, I was curious how the 'coproc' builtin
behaves. I
tried two commands, 'coproc ls' and 'coproc NAME ls' They both
appear to
use a NAME of 'COPROC', with the second attempting to run NAME (see the
last line of the output for what it's actually running).
My understanding of NAME comes from how it's used in the 'read'
command,
but I might be doing it wrong.
Repeat-By:
Pilot:~/tmp/bash-4.0 tim$ help coproc
coproc: coproc [NAME] command [redirections]
Create a coprocess named NAME.
Execute COMMAND asynchronously, with the standard output and
standard
input of the command connected via a pipe to file descriptors
assigned
to indices 0 and 1 of an array variable NAME in the executing
shell.
The default NAME is "COPROC".
Exit Status:
Returns the exit status of COMMAND.
Pilot:~/tmp/bash-4.0 tim$ coproc NAME ls
[1] 18474
Pilot:~/tmp/bash-4.0 tim$ ./bash: line 32: NAME: command not found
[1]+ Exit 127coproc COPROC NAME ls
Minor German localization itch
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables uname output: Linux passepartout.tim-landscheidt.de 2.6.30.10-105.2.23.fc11.i586 #1 SMP Thu Feb 11 06:51:26 UTC 2010 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 4.0 Patch Level: 23 Release Status: release Description: In a German environment, if there are no jobs, "fg" reports "Kein solche Job." Repeat-By: "LANG=de_DE.utf8 bash", "fg". Fix: It should read "Kein solche*r* Job."
"cd .." when WD unlinked gives wrong behaviour
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -m32 -march=i386 -mtune=pentium4 uname output: Linux gene.surrey.redhat.com 2.6.9-1.667 #1 Tue Nov 2 14:41:25 EST 2004 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.0 Patch Level: 16 Release Status: release Description: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149079 When the working directory has been unlinked, "cd .." should give an error exit status, but instead exits with code 0. Additionally, "pwd" (the built-in) appends "/.." to the previous working directory, rather than giving an error as it previously did. Repeat-By: $ mkdir -p /tmp/foo/bar $ cd /tmp/foo/bar $ rm -rf /tmp/foo $ cd .. cd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory $ echo $? 0 $ pwd /tmp/foo/bar/.. $ echo $? 0 $ pwd -P pwd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory $ pwd pwd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory Tim. */ pgpgBnmGpaYdK.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
PS1 \W behaviour: how to get the "old" way back?
In bash-3.0 this was added: kk. The `\W' prompt expansion now abbreviates $HOME as `~', like `\w'. It seems that a large number of people preferred things the way they were before, with \W giving the basename with no tilde abbreviation. Since there is no easy way of achieving this without resorting to PROMPT_COMMAND, could there be a new escape sequence added for it? Thanks, Tim. */ pgpOacT2TjhRR.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: PS1 \W behaviour: how to get the "old" way back?
On Wed, Feb 23, 2005 at 02:15:12PM -0500, Chet Ramey wrote:
> Unless I'm reading this wrong, ${PWD##*/} does the job (though it fails
> if PWD == '/'). You can always use $(basename $PWD).
Oh -- silly of me. I'd forgotten that PS1 gets expanded. ${PWD##/*/}
does what I want, except for the corner-case of '//'.
Thanks,
Tim.
*/
pgpulqY0nN6bm.pgp
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
compiler warnings
When compiling bash with GCC there are a number of alarming-looking warnings, and several of them could be avoided by minor changes to the code. For example: bashline.c:2976: warning: suggest parentheses around assignment used as truth value for (passc = 0; c = string[i]; i++) This could more readably be written: for (passc = 0; (c = string[i]) != '\0'; i++) Would you be willing to accept patches to make changes such as this? Thanks, Tim. */ pgpgihAgw6o76.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
control may reach end of non-void function
Hi,
In bash-3.0, bashline.c gives this warning during compilation:
bashline.c:1418: warning: control may reach end of non-void function
'bash_directory_expansion' being inlined
Since that function is only used once, and in that instance the return
value is not examined---and since there are no return statements in the
function at all---perhaps it should have its return type changed from
int to void.
Tim.
*/
--- bash-3.0/bashline.c.badcode 2005-03-08 13:16:39.0 +
+++ bash-3.0/bashline.c 2005-03-08 13:17:56.0 +
@@ -100,7 +100,7 @@
#endif
/* Helper functions for Readline. */
-static int bash_directory_expansion __P((char **));
+static void bash_directory_expansion __P((char **));
static int bash_directory_completion_hook __P((char **));
static int filename_completion_ignore __P((char **));
static int bash_push_line __P((void));
@@ -2200,7 +2200,7 @@
/* Simulate the expansions that will be performed by
rl_filename_completion_function. This must be called with the address of
a pointer to malloc'd memory. */
-static int
+static void
bash_directory_expansion (dirname)
char **dirname;
{
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
PS1 \W crash with PWD unset
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wall -g -pipe
-Wp,-D_FORTIFY_SOURCE=2 -m32 -march=i386 -mtune=pentium4
uname output: Linux gene.surrey.redhat.com 2.6.11-1.1176_FC4 #1 Mon Mar 7
02:10:55 EST 2005 i686 i686 i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu
Bash Version: 3.0
Patch Level: 16
Release Status: release
Description:
If PS1 contains '\W' but PWD becomes unset, for instance by
'unset PWD', bash segfaults. This is because the code
handling \W uses the result of get_string_value even if it is
NULL.
However, earlier in the code it does check for NULL and takes
appropriate action, so a guaranteed non-NULL version of the
result is already available. The fix is to use it.
Repeat-By:
PS1='\W'
unset PWD
Fix:
--- bash-3.0/parse.y.pwd2005-03-15 14:22:36.0 +
+++ bash-3.0/parse.y2005-03-15 14:22:37.0 +
@@ -4103,7 +4103,7 @@
#define ROOT_PATH(x) ((x)[0] == '/' && (x)[1] == 0)
#define DOUBLE_SLASH_ROOT(x) ((x)[0] == '/' && (x)[1] == '/' && (x)[2] == 0)
/* Abbreviate \W as ~ if $PWD == $HOME */
- if (c == 'W' && (((t = get_string_value ("HOME")) == 0) ||
STREQ (t, temp) == 0))
+ if (c == 'W' && (((t = get_string_value ("HOME")) == 0) ||
STREQ (t, t_string) == 0))
{
if (ROOT_PATH (t_string) == 0 && DOUBLE_SLASH_ROOT
(t_string) == 0)
{
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
sh -c 'kill -SIGTERM $$' -> 'invalid signal specification'
With bash-3.0.14, this command: sh -c 'kill -SIGTERM $$' gives this error: sh: line 0: kill: SIGTERM: invalid signal specification The man page for bash says that 'sigspec is either a case-insensitive signal name such as SIGKILL (with or without the SIG prefix)'. Should the documentation be corrected to mention that, if invoked as sh, the shell will not recognise the SIG prefix for the kill builtin? Tim. */ pgpexjSjmJtW4.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: sh -c 'kill -SIGTERM $$' -> 'invalid signal specification'
On Fri, Mar 18, 2005 at 10:33:29AM -0500, Chet Ramey wrote: > Since the behavior is as it stands because of Posix requirements, it > appears that I should copy the posix mode section of the texinfo manual > to the man page. After all, it's not long enough now. Oops! I'll have to remember to look there as well as the FAQ before posting. Sorry! Tim. */ pgpZED7uqZFPs.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: ((...) && (...)) parsing confused by line break
Hi Chet, I think you said you'd fixed this bug. Could you post the patch you used please? Thanks, Tim. */ On Mon, Jan 31, 2005 at 12:15:39PM +0000, Tim Waugh wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i386 > OS: linux-gnu > Compiler: i386-redhat-linux-gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' > -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -D_FORTIFY_SOURCE=2 -m32 -march=i386 > -mtune=pentium4 > uname output: Linux gene.surrey.redhat.com 2.6.9-1.667 #1 Tue Nov 2 14:41:25 > EST 2004 i686 i686 i386 GNU/Linux > Machine Type: i386-redhat-linux-gnu > > Bash Version: 3.0 > Patch Level: 16 > Release Status: release > > Description: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146638 > > This script fails: > > ( (echo line1) \ > && (echo line2)) > ((echo line3) && (echo line4)) > ((echo line5) \ > && (echo line6)) > >like this: > > line1 > line2 > line3 > line4 > test.sh: line 5: syntax error near unexpected token `' > test.sh: line 5: `&& (echo line6))' > > It seems as though the problem line might be being treated as > though it is a ((...)) compound command, rather than nested > subshells. > > Repeat-By: > bash test.sh > ___ > Bug-bash mailing list > Bug-bash@gnu.org > http://lists.gnu.org/mailman/listinfo/bug-bash pgp5k6xbxrKqG.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [patch] Re: Job-handling bug in bash-3.0 and bash-2.05b
This job-handling bug is still present. Chet, would you mind commenting on it? Thanks, Tim. */ pgpFxUtUb4RoU.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
">/inaccessible" gives incorrect error
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wall -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -m32 -march=i386 -mtune=pentium4 uname output: Linux gene.surrey.redhat.com 2.6.11-1.1176_FC4 #1 Mon Mar 7 02:10:55 EST 2005 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.0 Patch Level: 16 Release Status: release Description: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155373 Running ">/inaccessible" as a normal user results in the error "No such file or directory" rather than the expected "Permission denied". This is due to AFS support. Repeat-By: >/inaccessible Fix: --- bash-3.0/redir.c.afs2005-04-20 09:16:15.0 +0100 +++ bash-3.0/redir.c2005-04-20 09:16:58.0 +0100 @@ -596,7 +596,9 @@ fd = open (filename, flags, mode); #if defined (AFS) if ((fd < 0) && (errno == EACCES)) - fd = open (filename, flags & ~O_CREAT, mode); + if ((fd = open (filename, flags & ~O_CREAT, mode)) < 0) + /* Restore previous errno. */ + errno = EACCES; #endif /* AFS */ } ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bug in bash handling of PS1 prompt
On Wed, Jun 22, 2005 at 03:21:46PM -0700, [EMAIL PROTECTED] wrote: > When assigning to PS1 to change the prompt, bash > appears to append any new value to the initial default > value, rather than to replace it. I expect you have PROMPT_COMMAND set. Tim. */ pgpZD44ZaRlI8.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Update on parent exiting after background command substitution
On Thu, Jun 30, 2005 at 08:57:07AM -0400, Chet Ramey wrote: > This is a classic race condition. It's already been fixed for the > next version. Is it possible to see what the fix is? It seems like quite a nasty bug! Tim. */ pgpJZpbgzWPwb.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
unsafe signal handler
The signal handler termination_unwind_protect() can call maybe_save_shell_history() -> append_history() -> history_do_write() -> history_filename() -> xmalloc() -> malloc() and malloc() is not safe to call from a signal handler. This affects bash-2.05b as well as bash-3.0. Tim. */ ref 163235 pgpvkkALlQaTC.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: unsafe signal handler
Further information on unsafe functions used in signal handlers: a brief inspection of the code in the termination_unwind_protect() handler revealed other instances than the one highlighted before: run_interrupt_trap->_run_trap_internal->savestring->xmalloc (and more like that) maybe_save_shell_history->append_history append_history->history_do_write maybe_save_shell_history->write_history write_history->history_do_write history_do_write->savestring->xmalloc history_do_write->xmalloc history_do_write->malloc history_do_write->mmap unlink_fifo_list->free run_exit_trap->savestring->xmalloc run_exit_trap->setjmp? run_exit_trap->reset_parser->free run_exit_trap->parse_and_execute->begin_unwind_frame->...->uwpalloc->xmalloc (and more like that) So regardless of the bash malloc() implementation, mmap() and setjmp() are used from this signal handler and they may not be. (However, I haven't been able to trigger either of these cases yet.) Tim. */ pgpUmTfDvP2oz.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: unsafe signal handler
I am looking at bash-3.0, trying to untangle the
termination_unwind_protect() signal handler. I cannot work out under
what circumstances the function run_interrupt_trap() is called.
sighandler
termination_unwind_protect (sig)
int sig;
{
if (sig == SIGINT && signal_is_trapped (SIGINT))
run_interrupt_trap ();
If I run "trap 'echo foxtrot' SIGINT", the signal hander seems to be
changed to trap_handler(), and so termination_unwind_protect() is not
called.
Can those two lines at the top of termination_unwind_protect() be
removed?
Tim.
*/
pgpy3L4cgb2nQ.pgp
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
declare/typeset can't set array to variable name
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin17.0.0
Compiler: clang
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='darwin17.0.0'
-DCONF_MACHTYPE='x86_64-apple-darwin17.0.0' -DCONF_VENDOR='apple'
-DLOCALEDIR='/usr/local/Cellar/bash/4.4.12/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I.
-I./include -I./lib -I./lib/intl
-I/private/tmp/bash-20170916-80428-1663r/bash-4.4/lib/intl
-DSSH_SOURCE_BASHRC -Wno-parentheses -Wno-format-security
uname output: Darwin TimBookPro.local 17.3.0 Darwin Kernel Version
17.3.0: Thu Nov 9 18:09:22 PST 2017;
root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
Machine Type: x86_64-apple-darwin17.0.0
Bash Version: 4.4
Patch Level: 12
Release Status: release
Description:
Declare/typeset throws error when trying to create a new array to a
name held in a variable.
Repeat-By:
tim@TimBookPro:~/ declare var1=( This works )
tim@TimBookPro:~/ var2=var3
tim@TimBookPro:~/ declare ${var2}="And this works"
tim@TimBookPro:~/ declare ${var2}=( This breaks )
-bash: syntax error near unexpected token `('
tim@TimBookPro:~/ declare -a ${var2}=( array flag doesnt matter )
-bash: syntax error near unexpected token `('
Re: declare/typeset can't set array to variable name
On Fri, Jan 5, 2018 at 8:02 AM, Chet Ramey wrote:
> On 1/4/18 9:27 PM, Tim Burnham wrote:
>
>> Bash Version: 4.4
>> Patch Level: 12
>> Release Status: release
>>
>> Description:
>> Declare/typeset throws error when trying to create a new array to a
>> name held in a variable.
>>
>> Repeat-By:
>> tim@TimBookPro:~/ declare var1=( This works )
>> tim@TimBookPro:~/ var2=var3
>> tim@TimBookPro:~/ declare ${var2}="And this works"
>> tim@TimBookPro:~/ declare ${var2}=( This breaks )
>> -bash: syntax error near unexpected token `('
>> tim@TimBookPro:~/ declare -a ${var2}=( array flag doesnt matter )
>> -bash: syntax error near unexpected token `('
>
> It's a syntax error. `declare' is a `declaration command', as Posix
> terms them, and takes assignment statements as arguments. If the parser
> can detect an argument to `declare' as a valid assignment statement, it
> will allow syntax, such as compound assignments, that it allows for
> standalone assignments. In this case, the `${var2}' on the left side
> of the assignment renders that word an invalid assignment statement,
> since `${var2}' is not a valid identifier. Because it's not an assignment
> statement, the left paren is not allowed to begin a compound assignment
> and is treated as the operator it usually is. This isn't a place where the
> grammar allows a left paren, so it's a syntax error.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Why does the parser inconsistently detect the identifier `${var2}'? In
the 3rd line of my example, Bash assigns the given expression into
`${var3}' as intended.
loadables/rm not POSIX compliant
Hi, I just built bash from git master (3ba697465bc74fab513a26dea700cc82e9f4724e) and enabled the 'rm' loadable via enable -f ~/src/bash/examples/loadables/rm rm Now, the next './configure' (autotools) says: # rm: usage: rm [-rf] file ... Oops! Your 'rm' program seems unable to run without file operands specified on the command line, even when the '-f' option is present. This is contrary to the behaviour of most rm programs out there, and not conforming with the upcoming POSIX standard: <http://austingroupbugs.net/view.php?id=542> Please tell bug-autom...@gnu.org about your system, including the value of your $PATH and any error possibly output before this message. This can help us improve future automake versions. Aborting the configuration process, to ensure you take notice of the issue. You can download and install GNU coreutils to get an 'rm' implementation that behaves properly: <https://www.gnu.org/software/coreutils/>. If you want to complete the configuration process using your problematic 'rm' anyway, export the environment variable ACCEPT_INFERIOR_RM_PROGRAM to "yes", and re-run configure. configure: error: Your 'rm' program is bad, sorry. # Is it possible to fix the loadable 'rm' command ? Let me know if you want me to provide a patch. Regards, Tim signature.asc Description: OpenPGP digital signature
Re: loadables/rm not POSIX compliant
On 5/28/19 4:38 PM, Chet Ramey wrote: > On 5/28/19 8:32 AM, Tim Rühsen wrote: > >> configure: error: Your 'rm' program is bad, sorry. >> # >> >> Is it possible to fix the loadable 'rm' command ? >> Let me know if you want me to provide a patch. > > Well, it's hard to know exactly what the problem is here, despite the > volumes of text produced, because the error message doesn't include the > command it tried. > > I assume we can fix this particular problem by having rm return 0 if there > aren't any operands and -f was supplied. That fix is attached. Thanks, LGTM and works for me. I meanwhile applied similar code, but having it upstream is way better :-) > If it's somthing else, there is code in bash, used by the loadable > builtins, to return a special status that causes the execution code to fall > back to the disk version of a command. The `rm' loadable already uses it > for `-i'. We just need to add it for additional cases. I guess -r and -f are all we need for standard ./configure runs. That's my main point for using rm as loadable, rm gets invoked easily by 1-2k times here for a single run. Since distributions like Debian doesn't deliver binaries from examples/, how can we get the rm loadable into builtins/ ? (What is missing that has to be done). Regards, Tim signature.asc Description: OpenPGP digital signature
Re: loadables/rm not POSIX compliant
On 5/28/19 6:04 PM, G. Branden Robinson wrote: > At 2019-05-28T17:01:52+0200, Tim Rühsen wrote: >> Since distributions like Debian doesn't deliver binaries from >> examples/, > > That doesn't sound accurate to me. The Debian Policy Manual, §12.6, > encourages the shipping of examples: > > https://www.debian.org/doc/debian-policy/ch-docs.html#examples > > In fact, the bash-doc package contains dozens of examples. However, I > don't see anything named "rm". (I'm looking at bash-doc 5.0-4 in Debian > 10, "buster".) That package does not contain examples/loadables. But there is a package 'bash-builtins' which doesn't contain 'rm' and 'cat' either. Opening a new bug report via 'reportbug' seems to trigger another Debian bug. You can see the bug entry at https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=bash-builtins (#929702), but clicking on it gives "There is no record of Bug #929702". That makes me feel sick. Also, I opened a similar bug at Debian years ago - but it's not on the list of bash or bash-builtins any more. Seems like bugs become removed or are "lost" somehow sometimes. No idea what happened. Thanks for motivating me to create a (/another) bug for this issue. Regards, Tim signature.asc Description: OpenPGP digital signature
Re: loadables/rm not POSIX compliant
On 5/29/19 12:53 PM, Tim Rühsen wrote: > On 5/28/19 6:04 PM, G. Branden Robinson wrote: >> At 2019-05-28T17:01:52+0200, Tim Rühsen wrote: >>> Since distributions like Debian doesn't deliver binaries from >>> examples/, >> >> That doesn't sound accurate to me. The Debian Policy Manual, §12.6, >> encourages the shipping of examples: >> >> https://www.debian.org/doc/debian-policy/ch-docs.html#examples >> >> In fact, the bash-doc package contains dozens of examples. However, I >> don't see anything named "rm". (I'm looking at bash-doc 5.0-4 in Debian >> 10, "buster".) > > That package does not contain examples/loadables. But there is a package > 'bash-builtins' which doesn't contain 'rm' and 'cat' either. > > Opening a new bug report via 'reportbug' seems to trigger another Debian > bug. You can see the bug entry at > https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=bash-builtins > (#929702), but clicking on it gives "There is no record of Bug #929702". The link now works (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929702). It took a while, I was too impatient. Regards, Tim signature.asc Description: OpenPGP digital signature
declare -p my_function does not print its definition. A bug?
Hi,
when I define the following function:
$ function foo {
> echo bar
> }
and try to run it, I get:
$ foo
bar
but try to print its definition with "declare", I get:
$ declare -p foo
bash: declare: foo: not found
$ declare -pf foo
bash: declare: foo: not found
$declare -pF foo
bash: declare: foo: not found
but try to print its definition with "type", I get:
$ type foo
foo is a function
foo ()
{
echo bar
}
I'm running the above commands in the following environment:
* Fedora Linux 20 "Heisenbug"
* BASH_VERSION => 4.2.53(1)-release
* bash --version => GNU bash, version 4.2.53(1)-release
(x86_64-redhat-linux-gnu)
Any clue why the declare built-in does not print a function's definition?
BR
Tim
signature.asc
Description: OpenPGP digital signature
Subject: Manual directory stack ambiguity
Machine: x86_64 OS: cygwin Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='x86_64-unknown-cygwin' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I. -I/usr/src/bash-4.3.39-2.x86_64/src/bash-4.3 -I/usr/src/bash-4.3.39-2.x86_64/src/bash-4.3/include -I/usr/src/bash-4.3.39-2.x86_64/src/bash-4.3/lib -DWORDEXP_OPTION -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/usr/src/bash-4.3.39-2.x86_64/build=/usr/src/debug/bash-4.3.39-2 -fdebug-prefix-map=/usr/src/bash-4.3.39-2.x86_64/src/bash-4.3=/usr/src/debug/bash-4.3.39-2 uname output: CYGWIN_NT-6.1 DIENB090 2.1.0(0.287/5/3) 2015-07-14 21:28 x86_64 Cygwin Machine Type: x86_64-unknown-cygwin Bash Version: 4.3 Patch Level: 39 Release Status: release Description: There is a ambiguity about the directory stack in the manual: 6.8.1 Directory Stack Builtins It's difficult to understand if the current directory is part of the stack or not. For example : - description of the popd builtin : " popd [-n] [+N | -N] Remove the top entry from the directory stack, and 'cd' to the new top directory. When no arguments are given, 'popd' removes the top directory from the stack and performs a 'cd' to the new top directory. The elements are numbered from 0 starting at the first directory listed with 'dirs'; that is, 'popd' is equivalent to 'popd +0'. " By this description, one can understand that the current dir is the top directory, that it is removed and the new top directory is then used as current directory - description of the pushd builin: " pushd [-n] [+N | -N | DIR] Save the current directory on the top of the directory stack and then 'cd' to DIR. With no arguments, 'pushd' exchanges the top two directories. " By this one can understand that DIR will not be pushed on the stack. So after the operation, the current dir is not the first stacked directory. It also doesn't specify that the pushd operation wihtout argument will changes the current directory. It says that it swaps the top two directories. Again, not clear if it's talking about the current dir and the first stacked dir or the two first stacked dir. Within the whole manual node, it's never clear whether the directory stack includes the current directory or not. Repeat-By: Read the manual...
Re: Subject: Manual directory stack ambiguity
The commands work fine, and one understands pretty easily while playing with them how the stack works. There are just ambiguities in the manual. Check the pushd builtin command documentation. " `pushd' pushd [-n] [+N | -N | DIR] Save the current directory on the top of the directory stack and then `cd' to DIR. With no arguments, `pushd' exchanges the top two directories. " The first sentence implies that the current directory is not part of what the manual calls the "directory stack". The current directory is pushed on the stack and then the command cds to DIR (which will not be part of the stack). The second sentence says that the top two directories are exchanged with no arguments, but in practice it's the current dir and the top stack directory that are exchanged if we accept what they define as stack in the first sentence. In that perspective, the second sentence should be rewritten something like : "With no arguments, pushd exchanges the top stack directory with the current directory and cds to the old top directory". It's details, but I think the manual should state whether the stack includes the cd and correct those little ambiguities. What does it refer to when it uses terms like "top directory of the stack".. Is is the current dir or the last pushed directory ? 2015-08-16 13:51 GMT+02:00 Chet Ramey : > On 8/14/15 6:08 AM, Tim Nielens wrote: > > > Bash Version: 4.3 > > Patch Level: 39 > > Release Status: release > > > > Description: > > There is a ambiguity about the directory stack in the manual: 6.8.1 > > Directory Stack Builtins > > > > It's difficult to understand if the current directory is part of the > stack > > or not. > > `dirs' always displays the directory stack, and the current directory is > always the first element (sometimes the only one). > > The current directory is always the implicit top of the directory stack, > so things like popd and pushd without arguments can use it, so `dirs' lists > it as the first element. > > When you use pushd for the first time, for instance, you push the directory > given as an argument `on top' of the current directory, and make it the > new current directory, so it's the top of the stack for a subsequent pushd > or popd. > > If you haven't pushed anything, there's nothing to pop, and `popd' returns > an error message. If you have pushed something, you pop the current > directory and return to the immediately previous one. > > pushd always changes the current directory unless the -n option is given. > Since the `topmost' element of the stack is always the current directory, > popd will change the current directory if it operates on the top element > (popd, popd +0), unless the -n option is given. > > Since a successful `pushd' or `popd' always prints the contents of the > directory stack, there should not be too much confusion about its members. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ >
Re: 'cat' and 'rm' as builtins ?
On Sonntag, 30. Oktober 2016 17:33:15 CET Tim Rühsen wrote: > Hi, > > currently, some GNU people are developing ideas and code to speed up the GNU > toolchain (autotools, make). > > A simple ./configure for wget calls 'cat' ~2000 times, same with 'rm'. > This sums up to a roughly 5-10% of the overall time used in ./configure. > > Since cat and rm implementations are pretty small in code size, I wonder if > you (the maintainers) would accept patches to make these commands builtin > commands. > > To keep backward compatibility for sure, these builtins could be disabled by > default. A following small change in autotools could enable these. > > My current plan is to use the builtin code for 'cat' only when no options > are given. If options are given, fall back to fork/exec. > > With 'rm' I would use builtin code for no options, for -r and for -f (and > -r/- f combined), else fall back to fork/exec. > > WDYT ? Sorry, me again =) Just found examples/loadables... If ./configure detects bash, it could load custom shared objects of course. Less invasive, just project-related, but more control outside of bash (e.g. one could enable the loadables from config.site file). Tim signature.asc Description: This is a digitally signed message part.
'cat' and 'rm' as builtins ?
Hi, currently, some GNU people are developing ideas and code to speed up the GNU toolchain (autotools, make). A simple ./configure for wget calls 'cat' ~2000 times, same with 'rm'. This sums up to a roughly 5-10% of the overall time used in ./configure. Since cat and rm implementations are pretty small in code size, I wonder if you (the maintainers) would accept patches to make these commands builtin commands. To keep backward compatibility for sure, these builtins could be disabled by default. A following small change in autotools could enable these. My current plan is to use the builtin code for 'cat' only when no options are given. If options are given, fall back to fork/exec. With 'rm' I would use builtin code for no options, for -r and for -f (and -r/- f combined), else fall back to fork/exec. WDYT ? Regards, Tim signature.asc Description: This is a digitally signed message part.
[PATCH] Add-rm-rf-as-examples-loadables-rm.c
Added the 'rm' command to examples/loadables.
It accepts -r and -f.
Enable it with 'enable -f /examples/loadables/rm rm'.
Tested on wget configure script where it increases overall execution time by
6-7%.
Tim
From 5f1a18e570e63c9f010c48aca3a3484f56045fd5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tim Rühsen?=
Date: Mon, 31 Oct 2016 12:44:20 +0100
Subject: [PATCH 2/2] Add rm [-rf] as examples/loadables/rm.c
---
MANIFEST | 1 +
examples/loadables/Makefile.in | 5 +-
examples/loadables/README | 1 +
examples/loadables/rm.c| 153 +
4 files changed, 159 insertions(+), 1 deletion(-)
create mode 100644 examples/loadables/rm.c
diff --git a/MANIFEST b/MANIFEST
index a306b6f..c352811 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -681,6 +681,7 @@ examples/loadables/dirname.c f
examples/loadables/tty.c f
examples/loadables/pathchk.c f
examples/loadables/tee.c f
+examples/loadables/rm.c f
examples/loadables/rmdir.c f
examples/loadables/head.c f
examples/loadables/printenv.c f
diff --git a/examples/loadables/Makefile.in b/examples/loadables/Makefile.in
index ec305cd..da0f595 100644
--- a/examples/loadables/Makefile.in
+++ b/examples/loadables/Makefile.in
@@ -103,7 +103,7 @@ INC = -I. -I.. -I$(topdir) -I$(topdir)/lib -I$(topdir)/builtins -I${srcdir} \
ALLPROG = print truefalse sleep finfo logname basename dirname \
tty pathchk tee head mkdir rmdir printenv id whoami \
uname sync push ln unlink realpath strftime mypid setpgid
-OTHERPROG = necho hello cat pushd
+OTHERPROG = necho hello cat pushd rm
all: $(SHOBJ_STATUS)
@@ -142,6 +142,9 @@ finfo: finfo.o
cat: cat.o
$(SHOBJ_LD) $(SHOBJ_LDFLAGS) $(SHOBJ_XLDFLAGS) -o $@ cat.o $(SHOBJ_LIBS)
+rm: rm.o
+ $(SHOBJ_LD) $(SHOBJ_LDFLAGS) $(SHOBJ_XLDFLAGS) -o $@ rm.o $(SHOBJ_LIBS)
+
logname: logname.o
$(SHOBJ_LD) $(SHOBJ_LDFLAGS) $(SHOBJ_XLDFLAGS) -o $@ logname.o $(SHOBJ_LIBS)
diff --git a/examples/loadables/README b/examples/loadables/README
index 2eae9cc..3d4e641 100644
--- a/examples/loadables/README
+++ b/examples/loadables/README
@@ -52,6 +52,7 @@ printenv.c Minimal builtin clone of BSD printenv(1).
push.c Anyone remember TOPS-20?
README README
realpath.c Canonicalize pathnames, resolving symlinks.
+rm.c Remove files, and directories with -r.
rmdir.c Remove directory.
sleep.c sleep for fractions of a second.
strftime.c Loadable builtin interface to strftime(3).
diff --git a/examples/loadables/rm.c b/examples/loadables/rm.c
new file mode 100644
index 000..b10e4d9
--- /dev/null
+++ b/examples/loadables/rm.c
@@ -0,0 +1,153 @@
+/* rm - remove files */
+
+/* See Makefile for compilation details. */
+
+/*
+ Copyright (C) 2016 Free Software Foundation, Inc.
+
+ This file is part of GNU Bash.
+ Bash is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+
+ Bash is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with Bash. If not, see <http://www.gnu.org/licenses/>.
+*/
+
+#include "config.h"
+
+#include
+#include
+#include
+#include "builtins.h"
+#include "shell.h"
+#include "common.h"
+
+#if !defined (errno)
+extern int errno;
+#endif
+
+static int
+_rm_file(const char *fname);
+
+static int force, recursive;
+
+static int
+_remove_directory(const char *dirname)
+{
+ DIR *dir;
+ struct dirent *dp;
+ size_t dirlen = strlen(dirname);
+ int err = 0;
+
+ if ((dir = opendir(dirname)))
+{
+ while ((dp = readdir(dir)))
+{
+ if (*dp->d_name == '.' && (dp->d_name[1] == 0 || (dp->d_name[1] == '.' && dp->d_name[2] == 0)))
+continue;
+
+ char fname[dirlen + 1 + strlen(dp->d_name) + 1];
+ snprintf(fname, sizeof(fname), "%s/%s", dirname, dp->d_name);
+
+ if (_rm_file (fname) && !force)
+ err = 1;
+}
+
+ closedir(dir);
+
+ if (!err && rmdir(dirname) && !force)
+err = 1;
+}
+ else if (!force)
+err = 1;
+
+ if (err)
+builtin_error ("%s: %s", dirname, strerror (errno));
+
+ return err;
+}
+
+static int
+_rm_file(const char *fname)
+{
+ if (unlink (fname) == 0)
+return 0;
+
+ /* in case name is a directory glibc returns EISDIR but correct POSIX value would be EPERM */
+ if ((errno == EISDIR || errno == EPERM) && recursive)
+return _remove_directory(fname);
+ else if (force)
+return 0;
+
+ builtin_error (&quo
[PATCH] Fix-gcc-warnings-in-examples-loadables-cat.c
Just saw and fixed few warnings on 'make others' in examples/loadable.
Tim
From dd84f7ab279f6d2ad38618280ed45eff21fab07e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tim Rühsen?=
Date: Mon, 31 Oct 2016 12:43:42 +0100
Subject: [PATCH 1/2] Fix gcc warnings in examples/loadables/cat.c
---
examples/loadables/cat.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/examples/loadables/cat.c b/examples/loadables/cat.c
index 1ce2e2d..a996e6f 100644
--- a/examples/loadables/cat.c
+++ b/examples/loadables/cat.c
@@ -42,7 +42,7 @@ int fd;
char buf[1024], *s;
int n, w, e;
- while (n = read(fd, buf, sizeof (buf))) {
+ while ((n = read(fd, buf, sizeof (buf {
w = write(1, buf, n);
if (w != n) {
e = errno;
@@ -56,7 +56,7 @@ int fd;
return 0;
}
-cat_main (argc, argv)
+int cat_main (argc, argv)
int argc;
char **argv;
{
@@ -88,7 +88,7 @@ char **argv;
return (r);
}
-cat_builtin(list)
+int cat_builtin(list)
WORD_LIST *list;
{
char **v;
--
2.10.2
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] Add-rm-rf-as-examples-loadables-rm.c
On Monday, October 31, 2016 7:08:51 AM CET John McKown wrote: > On Mon, Oct 31, 2016 at 6:59 AM, Tim Ruehsen wrote: > > Added the 'rm' command to examples/loadables. > > > > It accepts -r and -f. > > Enable it with 'enable -f /examples/loadables/rm rm'. > > > > Tested on wget configure script where it increases overall execution time > > by > > 6-7%. > > Am I understand you correctly? You say that it __increases__ overall > execution time? That is, using rm as a builtin makes the script take more > time to execute (slows it down)? Sorry, me in a hurry ;-) I meant it *decreases* execution time. Tim signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Add-rm-rf-as-examples-loadables-rm.c
On Montag, 31. Oktober 2016 13:09:15 CET Chet Ramey wrote: > On 10/31/16 7:59 AM, Tim Ruehsen wrote: > > Added the 'rm' command to examples/loadables. > > > > It accepts -r and -f. > > Thanks for the submission. I modified it pretty heavily, and it will be > in the next release of bash and the next devel snapshot. Nice, thanks for the modifications. @Cedric Also thanks for your hints... would have cared about them tomorrow, but Chet was faster ;-) Tim signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Add-rm-rf-as-examples-loadables-rm.c
tils. 'rm' without > arguments prints a usage error and exits with nonzero status. But note > that POSIX requires 'rm -f' without arguments to silently exit with > success. POSIX only specifies the behavior of 'rm -f' without > arguments; with 'rm', you can do what you want (therefore you comply > with POSIX), but it's still nice to match what other implementations do. [**] As you say, preferable it should match with GNU coreutils in this point. > While I think that it is neat that this builtin can be used to speed up > configure scripts, I don't think it is ready for prime time yet. It's > tough to recommend that autoconf be taught to use this sub-standard > implementation. It works with all my configure scripts so far. I put the two enable commands into my config.site inside -n "$BASH" check, so nothing but ./configure is affected. With my current project, it gives me ~7% boost, just started a wiki page to document my effords (https://github.com/rockdaboot/wget2/wiki/Developer-hints:-Increasing-speed-of-GNU-toolchain). Still under construction, comments welcome. Back to "prime time"... IMO [*] and [**] would be enough for prime time. I don't see that further performance tuning and code complexity gives us any benefit with autotools. But if any project proofs the contrary, the responsible people are free to offer patches here. Anyways, a big *thank you* for your review. That also gave me a new view onto diropen/readdir complexity. Regards, Tim signature.asc Description: This is a digitally signed message part.
