some sed commands fail when in background
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
Some sed
commands seem to fail when run in background. Minimal example below.
One sed
command appends append
after a block of lines that begin with a star *
. The other just substitutes a word. The order of the sed
commands does not matter.
TEXT=$'* firstn'
two_seds()
sed "s/first/second/";
Executing two_seds & wait
results to:
* second
append
While executing wait & two_seds
yields:
* second
So the second sed
command always works, while the first does nothing after an &
.
While for now I know how to work around it, I would love to understand what's going on. Partly out of curiosity, partly so that it won't bite me later in obscure edge cases.
Can reproduce in bash
or dash
. Running:
Ubuntu 18.04
sed (GNU sed) 4.4
GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
dash, version 0.5.8-2.10
bash shell-script sed regular-expression dash
add a comment |
up vote
0
down vote
favorite
Some sed
commands seem to fail when run in background. Minimal example below.
One sed
command appends append
after a block of lines that begin with a star *
. The other just substitutes a word. The order of the sed
commands does not matter.
TEXT=$'* firstn'
two_seds()
sed "s/first/second/";
Executing two_seds & wait
results to:
* second
append
While executing wait & two_seds
yields:
* second
So the second sed
command always works, while the first does nothing after an &
.
While for now I know how to work around it, I would love to understand what's going on. Partly out of curiosity, partly so that it won't bite me later in obscure edge cases.
Can reproduce in bash
or dash
. Running:
Ubuntu 18.04
sed (GNU sed) 4.4
GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
dash, version 0.5.8-2.10
bash shell-script sed regular-expression dash
2
Is it your intention to use$!
as the last backgrounded-PID (since it's in double quotes), or as an address range "not the last line"?
– Jeff Schaller
Nov 27 at 18:08
The intention was to have it as "not the last line". The use of double quotes was because there are other variables there that need to be resolved. Apparently "not the last line" is not needed for my use case, so I can drop it.
– Boffin
Nov 28 at 8:58
Do you still see the problem after you drop the$!
?
– JigglyNaga
Nov 28 at 10:26
@JigglyNaga Nope, that solves it. It didn't do anything constructive anyways, since it's resolved to an empty string in the "working" case.
– Boffin
Nov 28 at 19:35
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Some sed
commands seem to fail when run in background. Minimal example below.
One sed
command appends append
after a block of lines that begin with a star *
. The other just substitutes a word. The order of the sed
commands does not matter.
TEXT=$'* firstn'
two_seds()
sed "s/first/second/";
Executing two_seds & wait
results to:
* second
append
While executing wait & two_seds
yields:
* second
So the second sed
command always works, while the first does nothing after an &
.
While for now I know how to work around it, I would love to understand what's going on. Partly out of curiosity, partly so that it won't bite me later in obscure edge cases.
Can reproduce in bash
or dash
. Running:
Ubuntu 18.04
sed (GNU sed) 4.4
GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
dash, version 0.5.8-2.10
bash shell-script sed regular-expression dash
Some sed
commands seem to fail when run in background. Minimal example below.
One sed
command appends append
after a block of lines that begin with a star *
. The other just substitutes a word. The order of the sed
commands does not matter.
TEXT=$'* firstn'
two_seds()
sed "s/first/second/";
Executing two_seds & wait
results to:
* second
append
While executing wait & two_seds
yields:
* second
So the second sed
command always works, while the first does nothing after an &
.
While for now I know how to work around it, I would love to understand what's going on. Partly out of curiosity, partly so that it won't bite me later in obscure edge cases.
Can reproduce in bash
or dash
. Running:
Ubuntu 18.04
sed (GNU sed) 4.4
GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
dash, version 0.5.8-2.10
bash shell-script sed regular-expression dash
bash shell-script sed regular-expression dash
asked Nov 27 at 17:54
Boffin
1032
1032
2
Is it your intention to use$!
as the last backgrounded-PID (since it's in double quotes), or as an address range "not the last line"?
– Jeff Schaller
Nov 27 at 18:08
The intention was to have it as "not the last line". The use of double quotes was because there are other variables there that need to be resolved. Apparently "not the last line" is not needed for my use case, so I can drop it.
– Boffin
Nov 28 at 8:58
Do you still see the problem after you drop the$!
?
– JigglyNaga
Nov 28 at 10:26
@JigglyNaga Nope, that solves it. It didn't do anything constructive anyways, since it's resolved to an empty string in the "working" case.
– Boffin
Nov 28 at 19:35
add a comment |
2
Is it your intention to use$!
as the last backgrounded-PID (since it's in double quotes), or as an address range "not the last line"?
– Jeff Schaller
Nov 27 at 18:08
The intention was to have it as "not the last line". The use of double quotes was because there are other variables there that need to be resolved. Apparently "not the last line" is not needed for my use case, so I can drop it.
– Boffin
Nov 28 at 8:58
Do you still see the problem after you drop the$!
?
– JigglyNaga
Nov 28 at 10:26
@JigglyNaga Nope, that solves it. It didn't do anything constructive anyways, since it's resolved to an empty string in the "working" case.
– Boffin
Nov 28 at 19:35
2
2
Is it your intention to use
$!
as the last backgrounded-PID (since it's in double quotes), or as an address range "not the last line"?– Jeff Schaller
Nov 27 at 18:08
Is it your intention to use
$!
as the last backgrounded-PID (since it's in double quotes), or as an address range "not the last line"?– Jeff Schaller
Nov 27 at 18:08
The intention was to have it as "not the last line". The use of double quotes was because there are other variables there that need to be resolved. Apparently "not the last line" is not needed for my use case, so I can drop it.
– Boffin
Nov 28 at 8:58
The intention was to have it as "not the last line". The use of double quotes was because there are other variables there that need to be resolved. Apparently "not the last line" is not needed for my use case, so I can drop it.
– Boffin
Nov 28 at 8:58
Do you still see the problem after you drop the
$!
?– JigglyNaga
Nov 28 at 10:26
Do you still see the problem after you drop the
$!
?– JigglyNaga
Nov 28 at 10:26
@JigglyNaga Nope, that solves it. It didn't do anything constructive anyways, since it's resolved to an empty string in the "working" case.
– Boffin
Nov 28 at 19:35
@JigglyNaga Nope, that solves it. It didn't do anything constructive anyways, since it's resolved to an empty string in the "working" case.
– Boffin
Nov 28 at 19:35
add a comment |
1 Answer
1
active
oldest
votes
up vote
10
down vote
accepted
The "$!"
at the beginning of your sed script ("$!N;/.*n...
) will expand to the PID of the last background job. Shell variables are expanded inside double quotes.
If no background job was yet run, it will expand to nothing, which is wrong, too (if you put the sed script in single quotes, it will go in an infinite loop).
Thanks a lot for solving this mystery @pizdelect. Much to learn, I have.
– Boffin
Nov 28 at 9:00
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
10
down vote
accepted
The "$!"
at the beginning of your sed script ("$!N;/.*n...
) will expand to the PID of the last background job. Shell variables are expanded inside double quotes.
If no background job was yet run, it will expand to nothing, which is wrong, too (if you put the sed script in single quotes, it will go in an infinite loop).
Thanks a lot for solving this mystery @pizdelect. Much to learn, I have.
– Boffin
Nov 28 at 9:00
add a comment |
up vote
10
down vote
accepted
The "$!"
at the beginning of your sed script ("$!N;/.*n...
) will expand to the PID of the last background job. Shell variables are expanded inside double quotes.
If no background job was yet run, it will expand to nothing, which is wrong, too (if you put the sed script in single quotes, it will go in an infinite loop).
Thanks a lot for solving this mystery @pizdelect. Much to learn, I have.
– Boffin
Nov 28 at 9:00
add a comment |
up vote
10
down vote
accepted
up vote
10
down vote
accepted
The "$!"
at the beginning of your sed script ("$!N;/.*n...
) will expand to the PID of the last background job. Shell variables are expanded inside double quotes.
If no background job was yet run, it will expand to nothing, which is wrong, too (if you put the sed script in single quotes, it will go in an infinite loop).
The "$!"
at the beginning of your sed script ("$!N;/.*n...
) will expand to the PID of the last background job. Shell variables are expanded inside double quotes.
If no background job was yet run, it will expand to nothing, which is wrong, too (if you put the sed script in single quotes, it will go in an infinite loop).
edited Nov 27 at 18:15
answered Nov 27 at 18:07
pizdelect
16114
16114
Thanks a lot for solving this mystery @pizdelect. Much to learn, I have.
– Boffin
Nov 28 at 9:00
add a comment |
Thanks a lot for solving this mystery @pizdelect. Much to learn, I have.
– Boffin
Nov 28 at 9:00
Thanks a lot for solving this mystery @pizdelect. Much to learn, I have.
– Boffin
Nov 28 at 9:00
Thanks a lot for solving this mystery @pizdelect. Much to learn, I have.
– Boffin
Nov 28 at 9:00
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f484491%2fsome-sed-commands-fail-when-in-background%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Is it your intention to use
$!
as the last backgrounded-PID (since it's in double quotes), or as an address range "not the last line"?– Jeff Schaller
Nov 27 at 18:08
The intention was to have it as "not the last line". The use of double quotes was because there are other variables there that need to be resolved. Apparently "not the last line" is not needed for my use case, so I can drop it.
– Boffin
Nov 28 at 8:58
Do you still see the problem after you drop the
$!
?– JigglyNaga
Nov 28 at 10:26
@JigglyNaga Nope, that solves it. It didn't do anything constructive anyways, since it's resolved to an empty string in the "working" case.
– Boffin
Nov 28 at 19:35