I often have situations where I want to split an existing var into
2 or more sub values. I usually use some combination of ${VAR<#|%>[<#|%>]expr},
but as soon as I don't check my break-down, I screw it up.
Which was front/back? Did I match the correct re with the correct
"truncate (or match) s
Linda Walsh wrote:
I suppose I'm presuming these features are not already implemented in
some fashion -- did I overlook them, or would they be 'new'?
I know it's not applicable for all cases, but I usually use read to
split strings into variables/an array.
J.
On Tue, Jun 29, 2010 at 03:29:17AM -0700, Linda Walsh wrote:
> I often have situations where I want to split an existing var into
> 2 or more sub values. I usually use some combination of
> ${VAR<#|%>[<#|%>]expr},
> but as soon as I don't check my break-down, I screw it up.
IFS='#%' read -r -a a
I have a bash script like this:
#!/bin/bash
trap 'echo killed by SIGALRM; exit 1' ALRM
function wait_kill()
{
sleep 5
kill -ALRM $$
}
wait_kill &
sleep 3600
### END OF THE SCRIPT ###
It does not work as I expected. The running script was not terminated after
5 seconds. So what's wron
On Wed, 30 Jun 2010, Clark J. Wang wrote:
> I have a bash script like this:
>
> #!/bin/bash
>
> trap 'echo killed by SIGALRM; exit 1' ALRM
>
> function wait_kill()
> {
> sleep 5
> kill -ALRM $$
> }
>
> wait_kill &
>
> sleep 3600
>
> ### END OF THE SCRIPT ###
>
> It does not work as
On Wed, Jun 30, 2010 at 12:38 PM, Chris F.A. Johnson
wrote:
> On Wed, 30 Jun 2010, Clark J. Wang wrote:
>
> > I have a bash script like this:
> >
> > #!/bin/bash
> >
> > trap 'echo killed by SIGALRM; exit 1' ALRM
> >
> > function wait_kill()
> > {
> > sleep 5
> > kill -ALRM $$
> > }
> >
>
On Wed, 30 Jun 2010, Clark J. Wang wrote:
> On Wed, Jun 30, 2010 at 12:38 PM, Chris F.A. Johnson
> wrote:
>
> > On Wed, 30 Jun 2010, Clark J. Wang wrote:
> >
> > > I have a bash script like this:
> > >
> > > #!/bin/bash
> > >
> > > trap 'echo killed by SIGALRM; exit 1' ALRM
> > >
> > > function w
Chris F.A. Johnson wrote:
$$ refers to the subshell.
There's no subshell here, I think.
The background process invoked by &.
$$ is meant to always report the "main shell", I'd guess this is true
for this case, too.
J.
On Wed, Jun 30, 2010 at 1:17 PM, Jan Schampera wrote:
> Chris F.A. Johnson wrote:
>
> $$ refers to the subshell.
>>>
>>> There's no subshell here, I think.
>>>
>>
>> The background process invoked by &.
>>
>
> $$ is meant to always report the "main shell", I'd guess this is true for
> th
Clark J. Wang wrote:
Running a cmd in background (by &) would not create subshell. Simple
testing:
#!/bin/bash
function foo()
{
echo $$
}
echo $$
foo &
### END OF SCRIPT ###
The 2 $$s output the same.
This doesn't mean that it doesn't create a subshell. It creates one,
since it can't
On Wed, Jun 30, 2010 at 1:40 PM, Jan Schampera wrote:
> Clark J. Wang wrote:
>
> Running a cmd in background (by &) would not create subshell. Simple
>> testing:
>>
>> #!/bin/bash
>>
>> function foo()
>> {
>>echo $$
>> }
>>
>> echo $$
>> foo &
>>
>> ### END OF SCRIPT ###
>>
>> The 2 $$s outp
On Wed, 30 Jun 2010, Clark J. Wang wrote:
> On Wed, Jun 30, 2010 at 1:40 PM, Jan Schampera wrote:
>
> > Clark J. Wang wrote:
> >
> > Running a cmd in background (by &) would not create subshell. Simple
> >> testing:
> >>
> >> #!/bin/bash
> >>
> >> function foo()
> >> {
> >>echo $$
> >> }
>
On Wed, Jun 30, 2010 at 9:12 AM, Clark J. Wang wrote:
> On Wed, Jun 30, 2010 at 1:40 PM, Jan Schampera
> wrote:
>
> > Clark J. Wang wrote:
> >
> > Running a cmd in background (by &) would not create subshell. Simple
> >> testing:
> >>
> >> #!/bin/bash
> >>
> >> function foo()
> >> {
> >>ech
On Wed, Jun 30, 2010 at 9:42 AM, Chris F.A. Johnson wrote:
> On Wed, 30 Jun 2010, Clark J. Wang wrote:
>
> > On Wed, Jun 30, 2010 at 1:40 PM, Jan Schampera
> wrote:
> >
> > > Clark J. Wang wrote:
> > >
> > > Running a cmd in background (by &) would not create subshell. Simple
> > >> testing:
> >
14 matches
Mail list logo
