RFE: 'list of vars' = split VAR
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) sense" %/#etc. I usually get it right when
I take the time to echo it to STDOUT, making the echo redundant, but
am subject to brain-o's when I don't echo it out (Murphy hides in my
brain, waiting for me to not verify things!)
I was thinking it would be so much easier and more efficient, if I
could have two features (yeah, I guess they are two separate features).
One would be the 'split' with an "expr" to split on, and a Var.
"Expr" would usually be 1 single character, but making it an
expression would make it more flexible.
Second part was the assignment to a list of variables in the place
of an array.
Currently:
a=(1 2 3)
does an array assignment. I'd like to see the ability to
specify a list of recipient vars, with the last being a "catchall"
that would become an array if there were multiple values still needing
L-value locations. I.e.:
(a b)=(1 2 3)
would assign 1 to 'a', and 'b' would become an array, with b[0]=2, b[1]=3.
Sure, I can do all these things manually with effort, but these would
simplify some common operations.
I suppose I'm presuming these features are not already implemented in
some fashion -- did I overlook them, or would they be 'new'?
If they are new, do they look useful enough to consider?
Thanks!
Linda
Re: RFE: 'list of vars' = split VAR
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.
Re: RFE: 'list of vars' = split VAR
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 array <<< "$string"
> One would be the 'split' with an "expr" to split on, and a Var.
> "Expr" would usually be 1 single character, but making it an
> expression would make it more flexible.
Multi-byte delimiters get ugly very, very fast. You can't use IFS for
those. Personally I would recommend moving up to awk/perl if you
need to deal with such cases.
> I'd like to see the ability to
> specify a list of recipient vars, with the last being a "catchall"
Like what read does? :-)
> that would become an array if there were multiple values still needing
> L-value locations. I.e.:
>
> (a b)=(1 2 3)
>
> would assign 1 to 'a', and 'b' would become an array, with b[0]=2, b[1]=3.
Oh... not quite like read, then. But this is an extremely bizarre request.
Assigning a scalar *and* an array in the same command, with no syntactic
differentiation between the two... wow.
> Sure, I can do all these things manually with effort, but these would
> simplify some common operations.
Common? Hah.
Anyway, if you really wanted to do the above, it would look something
like:
IFS='whatever' read -r -a b <<< "1 2 3"
a=${b[0]}
unset 'b[0]'
Now you have a "sparse" array (indexed from 1 to N instead of 0 to N)
and a scalar variable containing the former first element.
At the risk of assuming too much, I can't really imagine this being a
"common" requirement. For the most part, if you've got a list of options
or something where the first one is special, you simply pass the whole
option list to the command in question, and let IT shift off the first
option, instead of doing so yourself.
Or, if YOU are the command in question, you get the option list (argv)
and you write something like:
specialarg=$1
shift
Et voila.
Bash cannot kill itself?
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 wrong here?
-Clark
Re: Bash cannot kill itself?
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 I expected. The running script was not terminated after
> 5 seconds. So what's wrong here?
$$ refers to the subshell. Try:
trap 'echo killed by SIGALRM; exit 1' ALRM
function wait_kill()
{
sleep 5
kill -ALRM $pid
}
pid=$$
wait_kill &
sleep 3600
--
Chris F.A. Johnson,
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: Bash cannot kill itself?
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 $$
> > }
> >
> > 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 wrong here?
>
> $$ refers to the subshell.
There's no subshell here, I think.
> Try:
>
> trap 'echo killed by SIGALRM; exit 1' ALRM
>
> function wait_kill()
> {
>sleep 5
> kill -ALRM $pid
> }
>
> pid=$$
> wait_kill &
>
> sleep 3600
>
> --
> Chris F.A. Johnson,
> Author:
> Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
> Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
>
Re: Bash cannot kill itself?
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 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 wrong here?
> >
> > $$ refers to the subshell.
>
>
> There's no subshell here, I think.
The background process invoked by &.
> > Try:
> >
> > trap 'echo killed by SIGALRM; exit 1' ALRM
> >
> > function wait_kill()
> > {
> >sleep 5
> > kill -ALRM $pid
> > }
> >
> > pid=$$
> > wait_kill &
> >
> > sleep 3600
> >
> > --
> > Chris F.A. Johnson,
> > Author:
> > Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
> > Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
> >
>
--
Chris F.A. Johnson,
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: Bash cannot kill itself?
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.
Re: Bash cannot kill itself?
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
> this case, too.
>
> 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.
> J.
>
>
Re: Bash cannot kill itself?
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 replace your foreground process.
It just shows that $$ does what it should do, it reports the relevant
PID of the parent ("main") shell you use. As far as I can see, this
applies to all kinds of subshells like
- explicit ones (...)
- pipeline components
- command substitution
- process substitution
- async shells (like above, running your function)
- ...
J.
Re: Bash cannot kill itself?
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 output the same.
>>
>
> This doesn't mean that it doesn't create a subshell. It creates one, since
> it can't replace your foreground process.
>
> This makes sense.
It just shows that $$ does what it should do, it reports the relevant PID of
> the parent ("main") shell you use.
Then what's the problem with my script in my original mail? Seems like Bash
does not handle the signal in a real-time way.
As far as I can see, this applies to all kinds of subshells like
> - explicit ones (...)
> - pipeline components
> - command substitution
> - process substitution
> - async shells (like above, running your function)
> - ...
>
> J.
>
Re: Bash cannot kill itself?
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 $$
> >> }
> >>
> >> 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 replace your foreground process.
> >
> > This makes sense.
>
> It just shows that $$ does what it should do, it reports the relevant PID of
> > the parent ("main") shell you use.
>
>
> Then what's the problem with my script in my original mail? Seems like Bash
> does not handle the signal in a real-time way.
The special variable $$ refers to the current process, even if it
has the same numeric value as the parent script.
--
Chris F.A. Johnson,
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: Bash cannot kill itself?
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()
> >> {
> >>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 replace your foreground process.
> >
> > This makes sense.
>
> It just shows that $$ does what it should do, it reports the relevant PID
> of
> > the parent ("main") shell you use.
>
>
> Then what's the problem with my script in my original mail? Seems like Bash
> does not handle the signal in a real-time way.
>
> the signal is delivered after the foreground process "sleep 3600" exits,
try with:
"sleep 3600 & wait $!" instead
Re: Bash cannot kill itself?
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:
> > >>
> > >> #!/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 replace your foreground process.
> > >
> > > This makes sense.
> >
> > It just shows that $$ does what it should do, it reports the relevant PID
> of
> > > the parent ("main") shell you use.
> >
> >
> > Then what's the problem with my script in my original mail? Seems like
> Bash
> > does not handle the signal in a real-time way.
>
>The special variable $$ refers to the current process, even if it
> has the same numeric value as the parent script.
?!?
$$ is just a number.
