Three scripting questions
in [UK Linux]
|
From: Tom Anderson on 1 Mar 2010 07:21 On Mon, 1 Mar 2010, unruh wrote: > On 2010-02-28, Bruce Stephens <bruce+usenet(a)cenderis.demon.co.uk> wrote: >> "Chris F.A. Johnson" <cfajohnson(a)gmail.com> writes: >> >>> On 2010-02-28, Tom Anderson wrote: >> >>>> Firstly, i hear (from [1]) about a syntax that looks like $VARIABLE:t. >>>> I've never come across that. Is this a csh thing, does bash have an >>>> equivalent, and what does it do? >>> >>> I have no idea what that might mean in csh. >>> >>> In bash, it's a literal ':t' following whatever the variable >>> expands to. >>> >>> In a Bourne-type shell, such as bash, there are various expansion >>> involving braces, for example: ${x:-default} >>> >>> Check the parameter expansion section of the bash man page for more. >> >> You might expect it to be there, but you'd be mistaken. Look instead >> under history expansion (though I suspect it's almost always used on >> parameters). It's like basename: >> >> % a=foo/bar.baz >> % echo $a:t >> bar.baz >> >> (I don't have csh or tcsh installed, the above is in zsh.) > > In tcsh > [unruh]>export a=/usr/local/bin/a.b > wormhole[unruh]>tcsh > [unruh ~]$ echo $a > /usr/local/bin/a.b > [unruh ~]$ echo $a:t > a.b Okay, thanks. I will mentally file this under 'weird cshism' and then forget about it. tom -- Everyone in the world is doing something without me.
From: Richard Kettlewell on 1 Mar 2010 07:48 Tom Anderson <twic(a)urchin.earth.li> writes: > Now i just need to figure out why the script ignores SIGINT when it's > suspended then backgrounded. At a guess, you're comparing ^C on the foreground version to 'kill -INT $pid' to the background process. If so then the answer is probably: ^C sends a SIGINT to the entire process group (and the shell runs the command in a group unique to that command). So try 'kill -INT -$pid' instead. -- http://www.greenend.org.uk/rjk/
From: Tom Anderson on 1 Mar 2010 17:13 On Mon, 1 Mar 2010, Richard Kettlewell wrote: > Tom Anderson <twic(a)urchin.earth.li> writes: > >> Now i just need to figure out why the script ignores SIGINT when it's >> suspended then backgrounded. > > At a guess, you're comparing ^C on the foreground version to > 'kill -INT $pid' to the background process. > > If so then the answer is probably: ^C sends a SIGINT to the entire > process group (and the shell runs the command in a group unique to that > command). So try 'kill -INT -$pid' instead. Okay, that does the job, and you have transformed my problem from "how do i kill the script properly?" to "what the hell is this process group stuff about?". Thanks! tom -- The revolving disc of plagues is particularly fun. -- greengolux
From: Nix on 1 Mar 2010 19:05 On 28 Feb 2010, Tom Anderson told this: > Hi all, > > Firstly, i hear (from [1]) about a syntax that looks like $VARIABLE:t. I've never come across that. Is this a csh thing, does bash > have an equivalent, and what does it do? > > Secondly, i have a script which looks like: > > someprog & > someotherprog & > quit() { > shutdown-someprog > shutdown-someotherprog > } > trap quit 0 > while read line; do echo -n ""; done OK... > The idea is that the script starts some other programs (actually ssh > tunnels), then sits there doing nothing until someone sends it SIGINT > or SIGQUIT (or sends EOF to its stdin) something, at which point it > shuts then down cleanly. > > What's the best way to do the 'sit there doing nothing' part? I'm > using a do-nothing read loop, but that's actually not much good, Agreed. You want the underappreciated command 'wait'. Something like someprog & someotherprog & quit() { shutdown-someprog shutdown-someotherprog } trap quit SIGINT EXIT wait & 'wait' will exit when all the children die, and otherwise just call signal handlers. You can do really nifty things here, since the signal handlers can do pretty much anything, including redefining themselves or starting new processes. I've seen whole job schedulers written using nothing more.
From: Chris Davies on 2 Mar 2010 04:27
Nix <nix-razor-pit(a)esperi.org.uk> wrote: > wait & I really don't think that & should be there. Chris |