Re: feature request: "wait --free-slot" for poor man's parallelization
Mike Coleman wrote: Here's a bash feature I'd love to see, but don't have time to implement myself: a "--free-slot" flag to 'wait' that will wait until there is at least one free "slot" available, where a slot is basically a CPU core. Example usage: $ for ((n=0; n<100; n++)); do my_experiment $n > $n.out & wait --free-slot 4 done which I would run on a quad-CPU host. The meaning of the wait is: if I already have four background invocations of "my_experiment" running, wait until one finishes, then proceed. (If there are fewer than four running, proceed immediately.) This provides a nice sloppy way of letting me parallelize in a script without having to complicate things. "make -j" and "xargs -P" provide some of this capability, but are a lot more work to set up--I'd really like to have this at my fingertips for interactive stuff. I did something like that as a script, using an array of PIDs and a big loop and so on. I don't think it needs to be part of internal Bash features, it wasn't that much work. J.
Re: File renaming using SED in BASH
On Sep 22, 4:55 am, MisterMuv <[EMAIL PROTECTED]> wrote: > chg=echo $f |sed 's:(www.somewhere.net)::' > mv $f $chg > What am I doing wrong? just use this: mv "$f" "$chg", when your filenames are using spaces and other weird characters Also, I would suggest removing trailing spaces from filenames: for f in *; do chg=`echo $f | sed 's: (somewhere.net)::'`;mv "$f" "$chg"; done Yes, if you notice, you could forget nifty quotes ``, usually used for command execution.
Re: feature request: "wait --free-slot" for poor man's parallelization
On Fri, Oct 3, 2008 at 4:13 AM, Jan Schampera <[EMAIL PROTECTED]> wrote: > Mike Coleman wrote: >> >> Here's a bash feature I'd love to see, but don't have time to >> implement myself: a "--free-slot" flag to 'wait' that will wait until >> there is at least one free "slot" available, where a slot is basically >> a CPU core. >> >> Example usage: >> >> $ for ((n=0; n<100; n++)); do >> my_experiment $n > $n.out & >> wait --free-slot 4 >> done >> >> which I would run on a quad-CPU host. The meaning of the wait is: if >> I already have four background invocations of "my_experiment" running, >> wait until one finishes, then proceed. (If there are fewer than four >> running, proceed immediately.) >> >> This provides a nice sloppy way of letting me parallelize in a script >> without having to complicate things. "make -j" and "xargs -P" provide >> some of this capability, but are a lot more work to set up--I'd really >> like to have this at my fingertips for interactive stuff. > > I did something like that as a script, using an array of PIDs and a big loop > and so on. I don't think it needs to be part of internal Bash features, it > wasn't that much work. I'm sure this could be done with a script, but I'm imagining a scenario like the above where I don't need to get out an editor or anything--it'd be a quick-and-dirty thing I could type in at the command line. If there's a way to write "wait-free-slot" as a function (that could be source'd in), I'm all ears, but I don't see it. I guess it could poll the current children with ps, but that seems kind of ugly. Mike
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
Serge Dussud - Sun Microsystems wrote: > > Hello bug-bash, > > please find attached a bashbug report. I am not sure how to follow-up > then, could you advise ? This is the appropriate venue for these reports. I have a few questions about this one. 1. The trace shows that the process is not, in fact, using the bash malloc when it dies. The traced _malloc_unlocked and cleanfree functions are not in the bash malloc, but are present in libc. ff137068 sigacthandler (efe08, f706, 0, f8ca0, 0, 0) --- called from signal handler with signal 982536 (SIG Unknown) --- ff0e62a4 cleanfree (0, 8, ff1e64f8, ff1de63c, f83ec, 2) + 58 ff0e53d8 _malloc_unlocked (20, f7065554, efe00, f706, ff1e0468, ffdf) + 104 ff0e52b8 malloc (20, 0, 1, ff1de63c, f93c8, ff1e4864) + 48 2. What library installs the `sigacthandler'? It's not a function in bash. It is a symbol in libc, but there's no indication which library installs it as a signal handler. 3. What does the traceback look like when bash is run under gdb and allowed to fail? I suspect that the libraries are pre-bound to use the system's malloc, and the calls to different malloc libraries are causing the core dumps. Another possibility is that libc functions are using private pseudo- global libc malloc interfaces, causing the libc malloc to be linked in. Either way, the trace and library load address maps indicate that the process is dying in the libc malloc. One way to confirm my suspicion is to start bash under gdb, set a breakpoint in malloc, and see where it stops. If it's documented that applications on Solaris may no longer link with their own versions of malloc, that's fine -- I can arrange things so that bash doesn't try to use it's internal malloc on Solaris 10 and 11. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
