This might sound little familar to you guys, but am struck with something.
i have an IF conditioned loop which will determine a variable to get used in the later part of the script.
if [ blah = blah ];
then
if [ blah1=blah ];
then
Var_name="This is first line.This is second line.This is third line"
Now, when am using this Var_name in the later part of the script as mentioned below, its appearing as a whole line.
echo "For testing purpose ${Var_name}"
Please let me know what am doing here.
Note : I tried using single commands of echo -e "\n" in a shell script, its working fine. But when i tried to execute in a 50 lines shellscript its not working.
I tried to search in the forum ,for solutions, but am not able to find it. Hence , am posting a new thread.
Var_name="This is first line.
This is second line.
This is third line."
... remembering, of course, to quote the variable when used to preserve them in the output...
$ echo "$Var_name"
This is first line.
This is second line.
This is third line.
$ echo $Var_name
This is first line. This is second line. This is third line.
This method i have tried, but its not working as expected.
Let me give the complete overview of it ,
The Var_name is used as an variable to display the values in the HTML format table cell in mail as mentioned below,
<td ><b>Variable is :</b></td><td>"${Var_name}"</td>
Its not appearing as
"This is first line.
This is second line.
This is third line."
Now, in the same script, am using the same variable Var_name in an sed function to be parsed to replace a value with the variable value.
Original code :
sed 's/oldvalue/'"${Var_name}"'/g'
and its failing to get replaced,
Sed: Function s/oldvalue/##This is First Line. <br> cannot be parsed.
Is there any other options which we can do to get sorted.
MadeInGermany is correct, but you probably want to know why:
If you check the HTML source code you produce you will see that indeed there are three lines as Scott said and suggested. HTML source code, though, is not displayed as it is when you display it using a web browser. The browser interprets it and part of this interpretation is to "interpret away" the line breaks.
MadeInGermany just put the HTML equivalent of line breaks (the "<br />" tags) into the text, which will - when interpreted by a web browser - produce line breaks. Notice, that your text will, when showed in a web browser, look the same if you write:
Var_name="This is first line.<br />
This is second line.<br />
This is third line."
or
Var_name="This is first line.<br />This is second line.<br />This is third line."
because the "away-interpretation" of real line breaks works both ways: the browser simply ignores them and it will also ignore their absence.
I hope this helps.
bakunin
/PS: remove the (real) line breaks from your variables content, the browser would ignore them anyway. Their existence is probably the reason why your sed-statement is failing: web browsers ignore line breaks, but sed does not.
Well, there is a basic technique you might want to learn: escaping. That means: in some programs (here: sed, but the same goes for the shell too) certain characters (here: the "/") have a special meaning. We need a way to have them treated as normal characters, with their special meaning removed, sometimes.
If you want to use "/" as part of the search- and/or replacement string you will have to solve this, because changing i.e. "bla/blub" to "something/else" is not going to work this way. sed simply won't know what is part of the command and what is part of the strings to work on:
sed 's/bla/blub/something/else/g'
Fortunately there is a device - in fact two of them - you can use. The first is to change sed s special character: every character following the "s" command will be used, the only requirement is you have to use it consistently. To use "/" as a delimiter is just convention, not part of the syntax. The following two lines are equivalent and will both work:
sed 's_bla/blub_something/else_g'
sed 's!bla/blub!something/else!g'
The problem with this is that it shifts the problem only around: now you replaced "/" with another character you will have to worry about. Here is the definitive solution for that, more work, but final: you prepend the character in question with a "\". This will tell sed to not interpret the following character but take it literally:
sed 's/bla\/blub/something\/else/g'
Notice, that this works with "\" too - a "\\" will be interpreted as a literal backslash! You can even automatically "sedify" your variables before feeding them to sed . Try the following:
search="bla/blub"
replace="some/thing"
# naive way - will NOT work:
sed 's/'"${search}"'/'"${replace}"'/' /some/file > /some/otherfile
# but this works:
search="$(echo $search | sed 's/\//\\&/')"
replace="$(echo $replace | sed 's/\//\\&/')"
sed 's/'"${search}"'/'"${replace}"'/' /some/file > /some/otherfile
The application of this is left as an exercise to the interested reader. ;-))
Hi bakunin, that was an neat and clear explanation, really appreciate your help.
But am not that good in sed, so some how i have manged to understand whats the sed is doing in ur command.
But, still am getting error that it cannot be parsed to sed. .
Based on the If loop,
Var_name="This is first line.<br />This is second line.<br />This is third line."
sed: Function s/searchstring/This is first line.<br />This is second line.<br />This is third line./g cannot be parsed.
Modification as per your suggestion :
search="search_string"
Var_name="This is first line.<br />This is second line.<br />This is third line."
search="$(echo $search | sed 's/\//\\&/')"
replace="$(echo "$Var_name" | sed 's/\//\\&/')"
sed 's/'"${search}"'/'"${replace}"'/g' | sed 's/search/replace/g' > tmp_file
Please let me know what mistake am doing ?
---------- Post updated at 08:18 AM ---------- Previous update was at 07:22 AM ----------
Thanks Scrutinizer, That helps and fixed the issue as well perfectly. But am not able to find your post online, i got the mail, but am not able to find it here. I really want to thank you.
It may sound little weird, but am not able to see your reply.
I really appreciate the help from Scott and Scrutinizer.
.