semicolon at beginning of line

o world hello world $ echo hello;; echo world bash: syntax error near unexpected token `;;' $ ; echo hello world bash: syntax error near unexpected token `;' Any thoughts? Thanks, Elliott Forney

Re: semicolon at beginning of line

s "; ; ; echo hello world ; ; ;" although ksh only allows a single ; at the beginning of a line. On Sun, Apr 8, 2012 at 6:48 PM, Joseph Fredette wrote: > Could also use a #, no? > > On Sun, Apr 8, 2012 at 8:46 PM, Steven W. Orr wrote: > >> On 4/7/2012 4:00 PM, Elliott F

Re: semicolon at beginning of line

:~$ ${hello};${world} Thanks! Elliott Forney On Mon, Apr 9, 2012 at 10:02 PM, Elliott Forney wrote: > Sure, a comment can be used to place a line in your history but that > doesn't really address the examples I had.  Just seems to me like a > lone semicolon could be treated as a newline

Thanks!

Also, I just wanted to send out a thanks to Chet Ramey and everyone else that has contributed to bash. I am a bash junkie and use it every day. Not only is bash my primary interactive shell, it is also the scripting language that I write many of my programs in... and it glues together many of the

Re: status on $[arith] for eval arith vsl $((arith))??

that way there won't be an undocumented feature. Thanks, Elliott Forney On Mon, Apr 9, 2012 at 8:47 PM, Chet Ramey wrote: > On 4/9/12 9:07 PM, Linda Walsh wrote: >> >> >> Maarten Billemont wrote: >> >>> Any particular reason for not removing old undocume

Re: semicolon at beginning of line

is supported by the fact that this is already implemented in other shells. Try the examples I have given in zsh and you will see the behavior I would expect. Try it in ksh and you will see something closer to the blanket rule you suggest. If no one else agrees then that's cool but my vote is to change it. Thanks, Elliott Forney

Re: Parallelism a la make -j / GNU parallel

Here is a construct that I use sometimes... although you might wind up waiting for the slowest job in each iteration of the loop: maxiter=100 ncore=8 for iter in $(seq 1 $maxiter) do startjob $iter & if (( (iter % $ncore) == 0 )) then wait fi done On Thu, May 3, 2012 at 12:49 PM,

wait unblocks before signals processed

running: 3 sleeping: 2 nrunning: 3 sleeping: 1 nrunning: 3 sleeping: 2 nrunning: 3 start wait sleeping: 2 nrunning: 3 end wait $ ./par_sigusr: line 10: kill: (16287) - No such process ./par_sigusr: line 10: kill: (16287) - No such process Thanks! --- Elliott Forney

Re: wait unblocks before signals processed

Of course, this code probably also has a race condition around --nrunning which makes it even less usable. Thanks, --- Elliott ForneyE-Mail: id...@cs.colosetate.edu On Mon, Nov 5, 2012 at 4:33 PM, Elliott Forney wrote: > While trying to modify some code I found on

Re: wait unblocks before signals processed

d value in trap_list[17]: 0x4536e0 ./trap_race: warning: run_pending_traps: bad value in trap_list[17]: 0x4536e0 983 Thanks, --- Elliott Forney On Mon, Nov 5, 2012 at 5:11 PM, Dan Douglas wrote: > Hi Elliott. The behavior of wait differs depending upon whether you are in > POSIX m

Re: wait unblocks before signals processed

ap_race 4.2.37(3)-maint register_alloc: 0x9779a8 already in table as allocated? register_alloc: 0x979378 already in table as allocated? 100 Thanks, --- Elliott Forney

Re: wait unblocks before signals processed

$RANDOM } set -m trap ': $(( ++count ))' CHLD for i in {1..1000} do dummy $i & done wait echo $count Thanks, --- Elliott Forney On Tue, Nov 6, 2012 at 11:30 AM, Chet Ramey wrote: > On 11/5/12 11:34 PM, Elliott Forney wrote: > >> Sorry, I should look before p

flag for quiet CDPATH

the `cd' builtin had an option, say `-q', that would cause it to be quit if CDPATH is used. Then, I could simply alias cd='cd -q' and put a stop to this. I have attached a proposed patch, any thoughts? Thanks, --- Elliott ForneyE-Mail: id

Re: flag for quiet CDPATH

> +1 and `cd -' has the similar problem. So, I guess there are several cases to consider. 1. CDPATH 2. cdable_vars 3. - 4. cdspell I have attached another patch that would prevent echoing the path in all of these cases with the `-q` option. --- builtins/cd.def.orig 2014-01-20 16:52:02.00

Re: flag for quiet CDPATH

These are both good solutions, I was unaware of the builtin keyword or that redirection could come before the command :) Since cd doesn't appear to print anything else to stdout I would probably support leaving things as they are. Thanks!