[SOLVED] [BASH] here document creates problem with if-fi statemens.
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
[BASH] here document creates problem with if-fi statemens.
Hi guys!
I am reading the Advanced Bash Scripting and I decided to practice a bit and create my own little script.
I am trying to insert a little here document within an if-fi statement but i get a little problem:
Code:
if [ $0 = "mountemall" ]; then
[chunk of code]
cat <<SUCCESS
Operation Successful!
>>-----------------------------
$count files mounted correctly.
SUCCESS
fi
[more code]
I am using vi and this is what happens:
when you put the << to start the here document everything gets red bellow that point until you put the keyword. But in my case even though I put the keyword as I showed you the fi and everything below it stays in red as if it were commented...
now if I do this:
Code:
if [ $0 = "mountemall" ]; then
[chunk of code]
cat <<SUCCESS
Operation Successful!
>>-----------------------------
$count files mounted correctly.
fi
SUCCESS
[more code]
Then everything gets to normal color again... But i assume it will brake my if-fi statement...
Why does that happens?
if you want I can post the whole code in case the problem can be within the code itself.
Since the redirect into `cat`, once opened, will stay open until the process completes (or some other error occurs), you only need a single < to accomplish the task.
I tried your first example with only a single < and it works for me.
Since the redirect into `cat`, once opened, will stay open until the process completes (or some other error occurs), you only need a single < to accomplish the task.
I tried your first example with only a single < and it works for me.
Sasha
Thanks for the pointer, I did found out what was wrong... and it is stupid...
as you can see I was doing:
Code:
cat <<SUCCESS
[text]
SUCCESS
but vi is expecting:
Code:
cat <<SUCCESS
[text]
SUCCESS
for some reason vi appends the tab to the keyword and it kept looking for it... once i eliminated the space it right away worked as it should.
In the other hand I think that if you do "cat <SUCCESS" it will try to open a file called "SUCCESS" which doesnt exist, am I wrong on that?
#!/bin/bash
#temp file
cat <SUCCESS
this is a temp file
SUCCESS
returns:
Code:
[~]$ temp.sh
./temp.sh: line 4: SUCCESS: No such file or directory
./temp.sh: line 5: this: command not found
./temp.sh: line 6: SUCCESS: command not found
In my original code I am not using "cat <<SUCCESS > file" because I want the output to come to the stdout, im using it that way because:
Code:
echo
echo this
echo is
echo uglier
echo
Code:
cat <<END
than
something written like this
which is nicer...
END
One of the Here Document "gotchas" was you couldn't have a space between << (or <<-) and the delimiter word. I just checked the bash references and some examples in ABSG and that's how they show it, with no space, but Sasha's code works perfectly. A welcome change in the specification and thanks for illustrating it.
Thanks -- I almost always try to look into these sorts of threads (even if I can't provide *any* input) because not only are the various documentation sometimes outdated or contain typos, but as you mentioned, sometimes things get updated, and yet are not documented anywhere!
I find this << SUCCESS >> cat thread educational < as a whole >
because there are < cat EOF
so many different ways to > redirect things it's no wonder we get confused
Cheers,
Sasha
PS - here's a novelty I didn't know of till a few weeks ago: Did you guys know there's a `tac` command? It's the opposite of `cat` in that it starts at the END (or bottom) of a file/data stream, and works backwards
Last edited by GrapefruiTgirl; 08-26-2009 at 02:43 PM.
Another trick in here documents is that they permit shell substitution, so that you can embed shell variables, arithmetics and results of commands inside the block of code:
$ cat testfile
/home/alex
Wed Aug 26 21:43:40 CEST 2009
4
but if you embed one or more character of the limit string in quotes (double or single) the shell substitutions are not performed and the block of code is interpreted literally:
PS - here's a novelty I didn't know of till a few weeks ago: Did you guys know there's a `tac` command? It's the opposite of `cat` in that it starts at the END (or bottom) of a file/data stream, and works backwards
[off topic]
@ colucix -- P.S. I have always liked your signature!
[/off topic]
Thank you! I think it fits well to many issues about computers. Indeed I still wonder how it is possible that such a microscopic piece of silicon is able to accomplish so many tasks!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.