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-threa
ngle 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
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
ar {
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 f
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
se
# 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
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
;&>&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
ave any effect and a simple command still
makes it into history.
Cheers
Tim
/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.
Than
nvince 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 T
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
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, 201
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
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
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/s
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.
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
sign */
+ {
+ 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 parti
iption:
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
d=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
g 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,
27; | :
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
pecial 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
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/s
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/s
ays 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
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
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 &
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
> demonstr
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
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
ing
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
n 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
ed 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
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
, 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
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' -DPA
OR='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 Kern
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' -DPAC
/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
p
ng 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
hat 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
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@gn
ere 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 fun
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/s
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
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
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
> Comp
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
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/s
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
Descrip
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: PG
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
map() 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
(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.
*/
pgpy3L
s 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 unex
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
&
e-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
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 pr
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 th
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
ASH_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
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/sr
ludes 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 Ver
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'.
&g
t 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
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
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
---
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&
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
d 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.
72 matches
Mail list logo
