A while loop and an here-document - what happens when?
Clash Royale CLAN TAG#URR8PPP
up vote
6
down vote
favorite
I have this while loop and here-document combo which I run in Bash 4.3.48(1) and I don't understand its logic at all.
while read file; do source ~/unwe/"$file"
done <<-EOF
x.sh
y.sh
EOF
My question is comprised of these parts:
What does the
read
do here (I always useread
to declare a variable and assign its value interactively, but I'm missing what it's supposed to do here).What is the meaning of
while read
? Where does the concept ofwhile
come in here?If the here-document itself comes after the loop, how is it even affected by the loop? I mean, it comes after
done
, and not inside the loop, so what's the actual association between these two structures?Why does this fail?
while read file; do source ~/unwe/"$file" done <<-EOF
x.sh
y.sh
EOFI mean,
done
isdone
... So why does it matter ifdone <<-EOF
is on the same line as the loop? If I recall correctly, I did have a case in which afor
loop was one-liner and still worked.
text-processing variable read here-document control-flow
add a comment |Â
up vote
6
down vote
favorite
I have this while loop and here-document combo which I run in Bash 4.3.48(1) and I don't understand its logic at all.
while read file; do source ~/unwe/"$file"
done <<-EOF
x.sh
y.sh
EOF
My question is comprised of these parts:
What does the
read
do here (I always useread
to declare a variable and assign its value interactively, but I'm missing what it's supposed to do here).What is the meaning of
while read
? Where does the concept ofwhile
come in here?If the here-document itself comes after the loop, how is it even affected by the loop? I mean, it comes after
done
, and not inside the loop, so what's the actual association between these two structures?Why does this fail?
while read file; do source ~/unwe/"$file" done <<-EOF
x.sh
y.sh
EOFI mean,
done
isdone
... So why does it matter ifdone <<-EOF
is on the same line as the loop? If I recall correctly, I did have a case in which afor
loop was one-liner and still worked.
text-processing variable read here-document control-flow
add a comment |Â
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I have this while loop and here-document combo which I run in Bash 4.3.48(1) and I don't understand its logic at all.
while read file; do source ~/unwe/"$file"
done <<-EOF
x.sh
y.sh
EOF
My question is comprised of these parts:
What does the
read
do here (I always useread
to declare a variable and assign its value interactively, but I'm missing what it's supposed to do here).What is the meaning of
while read
? Where does the concept ofwhile
come in here?If the here-document itself comes after the loop, how is it even affected by the loop? I mean, it comes after
done
, and not inside the loop, so what's the actual association between these two structures?Why does this fail?
while read file; do source ~/unwe/"$file" done <<-EOF
x.sh
y.sh
EOFI mean,
done
isdone
... So why does it matter ifdone <<-EOF
is on the same line as the loop? If I recall correctly, I did have a case in which afor
loop was one-liner and still worked.
text-processing variable read here-document control-flow
I have this while loop and here-document combo which I run in Bash 4.3.48(1) and I don't understand its logic at all.
while read file; do source ~/unwe/"$file"
done <<-EOF
x.sh
y.sh
EOF
My question is comprised of these parts:
What does the
read
do here (I always useread
to declare a variable and assign its value interactively, but I'm missing what it's supposed to do here).What is the meaning of
while read
? Where does the concept ofwhile
come in here?If the here-document itself comes after the loop, how is it even affected by the loop? I mean, it comes after
done
, and not inside the loop, so what's the actual association between these two structures?Why does this fail?
while read file; do source ~/unwe/"$file" done <<-EOF
x.sh
y.sh
EOFI mean,
done
isdone
... So why does it matter ifdone <<-EOF
is on the same line as the loop? If I recall correctly, I did have a case in which afor
loop was one-liner and still worked.
text-processing variable read here-document control-flow
edited Feb 7 at 23:06
psmears
43528
43528
asked Feb 7 at 15:05
user9303970
123224
123224
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
11
down vote
accepted
The
read
command reads from its standard input stream and assigns what's read to the variablefile
(it's a bit more compicated than that, see long discussion here). The standard input stream is coming from the here-document redirected into the loop afterdone
. If not given data from anywhere, it will read from the terminal, interactively. In this case though, the shell has arranged to connect its input stream to the here-document.while read
will cause the loop to iterate until theread
command returns a non-zero exit status. This will happen if there are any errors, or (most commonly) when there is no more data to be read (its input stream is in an end-of-file state).The convention is that any utility that wishes to signal an error or "false" or "no" to the calling shell does so by returning a non-zero exit status. A zero exit status signals "true" or "yes" or "no error". This status, would you wish to inspect it, is available in
$?
(only from the last executed utility). The exit status may be used inif
statements andwhile
loops or anywhere where a test is required. For exampleif grep -q 'pattern' file; then ...; fi
A here-document is a form of redirection. In this case, it's a redirection into the loop. Anything inside the loop could read from it but in this case it's only the
read
command that does. Do read up on here-documents. If the input was coming from an ordinary file, the last line would have beendone <filename
Seeing the loop as one single command may make this more intuitive:
while ...; do ...; done <filename
which is one case of
somecommand <filename
Some shells also supports "here-strings" with
<<<"string"
:cat <<<"This is the here-string"
DavidFoerster points out that if any of the two scripts
x.sh
andy.sh
reads from standard input, without explicitly being given data to read from a file or from elsewhere, the data read will actually come from the here-document.With a
x.sh
that contains onlyread a
, this would make the variablea
contain the stringy.sh
, and they.sh
script would never run. This is due to the fact that the standard input is redirected for all commands in thewhile
loop (and also "inherited" by any invoked script or command) and the second line is "consumed" byx.sh
before thewhile
loop'sread
can read it.If this behaviour is unwanted, it can be avoided, but it's a bit tricky.
It fails because there is no
;
or newline beforedone
. Without;
or newline beforedone
, the worddone
will be taken as an argument ofsource
, and the loop will additionally not be properly closed (this is a syntax error).It is almost true that any
;
may be replaced by a newline (at least when it's a command delimiter). It signals the end of a command, as does|
,&
,&&
and||
(and probably others that I have forgotten).
3
+1 and one nitpick: "Anything inside the loop could read from it but in this case it's only theread
command that does." â Any or all of the sourced shell scripts (and their recursively invoked commands) can read from standard input and change the the loop invocations.
â David Foerster
Feb 7 at 16:48
@DavidFoerster That is correct. I was a bit blind to what the code actually did. I will add something about this.. soon.
â Kusalananda
Feb 7 at 16:50
Avoiding trouble with other things reading from stdin is fairly easy in this case; just pass the here-document in on unit 3 instead of stdin (... done 3<<-EOF
) and have theread
command read from unit 3 (while read file <&3; do ...
).
â Gordon Davisson
Feb 7 at 21:00
1
@GordonDavisson Yes it's easy, depending on your level of expertise and confidence. After more than 25 years at the command prompt, I still can only think of a handful of times (if that) that I've had to do file descriptor juggling like that, and I will always have to look it up :-)
â Kusalananda
Feb 7 at 21:04
add a comment |Â
up vote
2
down vote
You are in effect creating an object as a doc and then redirecting it back into a while loop that reads it line by line until there are no lines left, executing a source command on that line.
Another way to execute it is as follows:
Assuming that the lines
x.sh
y.sh
were in a file called:
input.txt
We could execute
cat input.txt | while read file
do source ~/unwe/"$file"
done
The here doc makes things more interactive but the above example may allow you to understand it better.
1
This other way is not equivalent to the original because the sourcing may happen in a subshell.
â Michael Homer
Feb 7 at 18:51
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
accepted
The
read
command reads from its standard input stream and assigns what's read to the variablefile
(it's a bit more compicated than that, see long discussion here). The standard input stream is coming from the here-document redirected into the loop afterdone
. If not given data from anywhere, it will read from the terminal, interactively. In this case though, the shell has arranged to connect its input stream to the here-document.while read
will cause the loop to iterate until theread
command returns a non-zero exit status. This will happen if there are any errors, or (most commonly) when there is no more data to be read (its input stream is in an end-of-file state).The convention is that any utility that wishes to signal an error or "false" or "no" to the calling shell does so by returning a non-zero exit status. A zero exit status signals "true" or "yes" or "no error". This status, would you wish to inspect it, is available in
$?
(only from the last executed utility). The exit status may be used inif
statements andwhile
loops or anywhere where a test is required. For exampleif grep -q 'pattern' file; then ...; fi
A here-document is a form of redirection. In this case, it's a redirection into the loop. Anything inside the loop could read from it but in this case it's only the
read
command that does. Do read up on here-documents. If the input was coming from an ordinary file, the last line would have beendone <filename
Seeing the loop as one single command may make this more intuitive:
while ...; do ...; done <filename
which is one case of
somecommand <filename
Some shells also supports "here-strings" with
<<<"string"
:cat <<<"This is the here-string"
DavidFoerster points out that if any of the two scripts
x.sh
andy.sh
reads from standard input, without explicitly being given data to read from a file or from elsewhere, the data read will actually come from the here-document.With a
x.sh
that contains onlyread a
, this would make the variablea
contain the stringy.sh
, and they.sh
script would never run. This is due to the fact that the standard input is redirected for all commands in thewhile
loop (and also "inherited" by any invoked script or command) and the second line is "consumed" byx.sh
before thewhile
loop'sread
can read it.If this behaviour is unwanted, it can be avoided, but it's a bit tricky.
It fails because there is no
;
or newline beforedone
. Without;
or newline beforedone
, the worddone
will be taken as an argument ofsource
, and the loop will additionally not be properly closed (this is a syntax error).It is almost true that any
;
may be replaced by a newline (at least when it's a command delimiter). It signals the end of a command, as does|
,&
,&&
and||
(and probably others that I have forgotten).
3
+1 and one nitpick: "Anything inside the loop could read from it but in this case it's only theread
command that does." â Any or all of the sourced shell scripts (and their recursively invoked commands) can read from standard input and change the the loop invocations.
â David Foerster
Feb 7 at 16:48
@DavidFoerster That is correct. I was a bit blind to what the code actually did. I will add something about this.. soon.
â Kusalananda
Feb 7 at 16:50
Avoiding trouble with other things reading from stdin is fairly easy in this case; just pass the here-document in on unit 3 instead of stdin (... done 3<<-EOF
) and have theread
command read from unit 3 (while read file <&3; do ...
).
â Gordon Davisson
Feb 7 at 21:00
1
@GordonDavisson Yes it's easy, depending on your level of expertise and confidence. After more than 25 years at the command prompt, I still can only think of a handful of times (if that) that I've had to do file descriptor juggling like that, and I will always have to look it up :-)
â Kusalananda
Feb 7 at 21:04
add a comment |Â
up vote
11
down vote
accepted
The
read
command reads from its standard input stream and assigns what's read to the variablefile
(it's a bit more compicated than that, see long discussion here). The standard input stream is coming from the here-document redirected into the loop afterdone
. If not given data from anywhere, it will read from the terminal, interactively. In this case though, the shell has arranged to connect its input stream to the here-document.while read
will cause the loop to iterate until theread
command returns a non-zero exit status. This will happen if there are any errors, or (most commonly) when there is no more data to be read (its input stream is in an end-of-file state).The convention is that any utility that wishes to signal an error or "false" or "no" to the calling shell does so by returning a non-zero exit status. A zero exit status signals "true" or "yes" or "no error". This status, would you wish to inspect it, is available in
$?
(only from the last executed utility). The exit status may be used inif
statements andwhile
loops or anywhere where a test is required. For exampleif grep -q 'pattern' file; then ...; fi
A here-document is a form of redirection. In this case, it's a redirection into the loop. Anything inside the loop could read from it but in this case it's only the
read
command that does. Do read up on here-documents. If the input was coming from an ordinary file, the last line would have beendone <filename
Seeing the loop as one single command may make this more intuitive:
while ...; do ...; done <filename
which is one case of
somecommand <filename
Some shells also supports "here-strings" with
<<<"string"
:cat <<<"This is the here-string"
DavidFoerster points out that if any of the two scripts
x.sh
andy.sh
reads from standard input, without explicitly being given data to read from a file or from elsewhere, the data read will actually come from the here-document.With a
x.sh
that contains onlyread a
, this would make the variablea
contain the stringy.sh
, and they.sh
script would never run. This is due to the fact that the standard input is redirected for all commands in thewhile
loop (and also "inherited" by any invoked script or command) and the second line is "consumed" byx.sh
before thewhile
loop'sread
can read it.If this behaviour is unwanted, it can be avoided, but it's a bit tricky.
It fails because there is no
;
or newline beforedone
. Without;
or newline beforedone
, the worddone
will be taken as an argument ofsource
, and the loop will additionally not be properly closed (this is a syntax error).It is almost true that any
;
may be replaced by a newline (at least when it's a command delimiter). It signals the end of a command, as does|
,&
,&&
and||
(and probably others that I have forgotten).
3
+1 and one nitpick: "Anything inside the loop could read from it but in this case it's only theread
command that does." â Any or all of the sourced shell scripts (and their recursively invoked commands) can read from standard input and change the the loop invocations.
â David Foerster
Feb 7 at 16:48
@DavidFoerster That is correct. I was a bit blind to what the code actually did. I will add something about this.. soon.
â Kusalananda
Feb 7 at 16:50
Avoiding trouble with other things reading from stdin is fairly easy in this case; just pass the here-document in on unit 3 instead of stdin (... done 3<<-EOF
) and have theread
command read from unit 3 (while read file <&3; do ...
).
â Gordon Davisson
Feb 7 at 21:00
1
@GordonDavisson Yes it's easy, depending on your level of expertise and confidence. After more than 25 years at the command prompt, I still can only think of a handful of times (if that) that I've had to do file descriptor juggling like that, and I will always have to look it up :-)
â Kusalananda
Feb 7 at 21:04
add a comment |Â
up vote
11
down vote
accepted
up vote
11
down vote
accepted
The
read
command reads from its standard input stream and assigns what's read to the variablefile
(it's a bit more compicated than that, see long discussion here). The standard input stream is coming from the here-document redirected into the loop afterdone
. If not given data from anywhere, it will read from the terminal, interactively. In this case though, the shell has arranged to connect its input stream to the here-document.while read
will cause the loop to iterate until theread
command returns a non-zero exit status. This will happen if there are any errors, or (most commonly) when there is no more data to be read (its input stream is in an end-of-file state).The convention is that any utility that wishes to signal an error or "false" or "no" to the calling shell does so by returning a non-zero exit status. A zero exit status signals "true" or "yes" or "no error". This status, would you wish to inspect it, is available in
$?
(only from the last executed utility). The exit status may be used inif
statements andwhile
loops or anywhere where a test is required. For exampleif grep -q 'pattern' file; then ...; fi
A here-document is a form of redirection. In this case, it's a redirection into the loop. Anything inside the loop could read from it but in this case it's only the
read
command that does. Do read up on here-documents. If the input was coming from an ordinary file, the last line would have beendone <filename
Seeing the loop as one single command may make this more intuitive:
while ...; do ...; done <filename
which is one case of
somecommand <filename
Some shells also supports "here-strings" with
<<<"string"
:cat <<<"This is the here-string"
DavidFoerster points out that if any of the two scripts
x.sh
andy.sh
reads from standard input, without explicitly being given data to read from a file or from elsewhere, the data read will actually come from the here-document.With a
x.sh
that contains onlyread a
, this would make the variablea
contain the stringy.sh
, and they.sh
script would never run. This is due to the fact that the standard input is redirected for all commands in thewhile
loop (and also "inherited" by any invoked script or command) and the second line is "consumed" byx.sh
before thewhile
loop'sread
can read it.If this behaviour is unwanted, it can be avoided, but it's a bit tricky.
It fails because there is no
;
or newline beforedone
. Without;
or newline beforedone
, the worddone
will be taken as an argument ofsource
, and the loop will additionally not be properly closed (this is a syntax error).It is almost true that any
;
may be replaced by a newline (at least when it's a command delimiter). It signals the end of a command, as does|
,&
,&&
and||
(and probably others that I have forgotten).
The
read
command reads from its standard input stream and assigns what's read to the variablefile
(it's a bit more compicated than that, see long discussion here). The standard input stream is coming from the here-document redirected into the loop afterdone
. If not given data from anywhere, it will read from the terminal, interactively. In this case though, the shell has arranged to connect its input stream to the here-document.while read
will cause the loop to iterate until theread
command returns a non-zero exit status. This will happen if there are any errors, or (most commonly) when there is no more data to be read (its input stream is in an end-of-file state).The convention is that any utility that wishes to signal an error or "false" or "no" to the calling shell does so by returning a non-zero exit status. A zero exit status signals "true" or "yes" or "no error". This status, would you wish to inspect it, is available in
$?
(only from the last executed utility). The exit status may be used inif
statements andwhile
loops or anywhere where a test is required. For exampleif grep -q 'pattern' file; then ...; fi
A here-document is a form of redirection. In this case, it's a redirection into the loop. Anything inside the loop could read from it but in this case it's only the
read
command that does. Do read up on here-documents. If the input was coming from an ordinary file, the last line would have beendone <filename
Seeing the loop as one single command may make this more intuitive:
while ...; do ...; done <filename
which is one case of
somecommand <filename
Some shells also supports "here-strings" with
<<<"string"
:cat <<<"This is the here-string"
DavidFoerster points out that if any of the two scripts
x.sh
andy.sh
reads from standard input, without explicitly being given data to read from a file or from elsewhere, the data read will actually come from the here-document.With a
x.sh
that contains onlyread a
, this would make the variablea
contain the stringy.sh
, and they.sh
script would never run. This is due to the fact that the standard input is redirected for all commands in thewhile
loop (and also "inherited" by any invoked script or command) and the second line is "consumed" byx.sh
before thewhile
loop'sread
can read it.If this behaviour is unwanted, it can be avoided, but it's a bit tricky.
It fails because there is no
;
or newline beforedone
. Without;
or newline beforedone
, the worddone
will be taken as an argument ofsource
, and the loop will additionally not be properly closed (this is a syntax error).It is almost true that any
;
may be replaced by a newline (at least when it's a command delimiter). It signals the end of a command, as does|
,&
,&&
and||
(and probably others that I have forgotten).
edited Feb 7 at 17:46
answered Feb 7 at 15:21
Kusalananda
103k13202318
103k13202318
3
+1 and one nitpick: "Anything inside the loop could read from it but in this case it's only theread
command that does." â Any or all of the sourced shell scripts (and their recursively invoked commands) can read from standard input and change the the loop invocations.
â David Foerster
Feb 7 at 16:48
@DavidFoerster That is correct. I was a bit blind to what the code actually did. I will add something about this.. soon.
â Kusalananda
Feb 7 at 16:50
Avoiding trouble with other things reading from stdin is fairly easy in this case; just pass the here-document in on unit 3 instead of stdin (... done 3<<-EOF
) and have theread
command read from unit 3 (while read file <&3; do ...
).
â Gordon Davisson
Feb 7 at 21:00
1
@GordonDavisson Yes it's easy, depending on your level of expertise and confidence. After more than 25 years at the command prompt, I still can only think of a handful of times (if that) that I've had to do file descriptor juggling like that, and I will always have to look it up :-)
â Kusalananda
Feb 7 at 21:04
add a comment |Â
3
+1 and one nitpick: "Anything inside the loop could read from it but in this case it's only theread
command that does." â Any or all of the sourced shell scripts (and their recursively invoked commands) can read from standard input and change the the loop invocations.
â David Foerster
Feb 7 at 16:48
@DavidFoerster That is correct. I was a bit blind to what the code actually did. I will add something about this.. soon.
â Kusalananda
Feb 7 at 16:50
Avoiding trouble with other things reading from stdin is fairly easy in this case; just pass the here-document in on unit 3 instead of stdin (... done 3<<-EOF
) and have theread
command read from unit 3 (while read file <&3; do ...
).
â Gordon Davisson
Feb 7 at 21:00
1
@GordonDavisson Yes it's easy, depending on your level of expertise and confidence. After more than 25 years at the command prompt, I still can only think of a handful of times (if that) that I've had to do file descriptor juggling like that, and I will always have to look it up :-)
â Kusalananda
Feb 7 at 21:04
3
3
+1 and one nitpick: "Anything inside the loop could read from it but in this case it's only the
read
command that does." â Any or all of the sourced shell scripts (and their recursively invoked commands) can read from standard input and change the the loop invocations.â David Foerster
Feb 7 at 16:48
+1 and one nitpick: "Anything inside the loop could read from it but in this case it's only the
read
command that does." â Any or all of the sourced shell scripts (and their recursively invoked commands) can read from standard input and change the the loop invocations.â David Foerster
Feb 7 at 16:48
@DavidFoerster That is correct. I was a bit blind to what the code actually did. I will add something about this.. soon.
â Kusalananda
Feb 7 at 16:50
@DavidFoerster That is correct. I was a bit blind to what the code actually did. I will add something about this.. soon.
â Kusalananda
Feb 7 at 16:50
Avoiding trouble with other things reading from stdin is fairly easy in this case; just pass the here-document in on unit 3 instead of stdin (
... done 3<<-EOF
) and have the read
command read from unit 3 (while read file <&3; do ...
).â Gordon Davisson
Feb 7 at 21:00
Avoiding trouble with other things reading from stdin is fairly easy in this case; just pass the here-document in on unit 3 instead of stdin (
... done 3<<-EOF
) and have the read
command read from unit 3 (while read file <&3; do ...
).â Gordon Davisson
Feb 7 at 21:00
1
1
@GordonDavisson Yes it's easy, depending on your level of expertise and confidence. After more than 25 years at the command prompt, I still can only think of a handful of times (if that) that I've had to do file descriptor juggling like that, and I will always have to look it up :-)
â Kusalananda
Feb 7 at 21:04
@GordonDavisson Yes it's easy, depending on your level of expertise and confidence. After more than 25 years at the command prompt, I still can only think of a handful of times (if that) that I've had to do file descriptor juggling like that, and I will always have to look it up :-)
â Kusalananda
Feb 7 at 21:04
add a comment |Â
up vote
2
down vote
You are in effect creating an object as a doc and then redirecting it back into a while loop that reads it line by line until there are no lines left, executing a source command on that line.
Another way to execute it is as follows:
Assuming that the lines
x.sh
y.sh
were in a file called:
input.txt
We could execute
cat input.txt | while read file
do source ~/unwe/"$file"
done
The here doc makes things more interactive but the above example may allow you to understand it better.
1
This other way is not equivalent to the original because the sourcing may happen in a subshell.
â Michael Homer
Feb 7 at 18:51
add a comment |Â
up vote
2
down vote
You are in effect creating an object as a doc and then redirecting it back into a while loop that reads it line by line until there are no lines left, executing a source command on that line.
Another way to execute it is as follows:
Assuming that the lines
x.sh
y.sh
were in a file called:
input.txt
We could execute
cat input.txt | while read file
do source ~/unwe/"$file"
done
The here doc makes things more interactive but the above example may allow you to understand it better.
1
This other way is not equivalent to the original because the sourcing may happen in a subshell.
â Michael Homer
Feb 7 at 18:51
add a comment |Â
up vote
2
down vote
up vote
2
down vote
You are in effect creating an object as a doc and then redirecting it back into a while loop that reads it line by line until there are no lines left, executing a source command on that line.
Another way to execute it is as follows:
Assuming that the lines
x.sh
y.sh
were in a file called:
input.txt
We could execute
cat input.txt | while read file
do source ~/unwe/"$file"
done
The here doc makes things more interactive but the above example may allow you to understand it better.
You are in effect creating an object as a doc and then redirecting it back into a while loop that reads it line by line until there are no lines left, executing a source command on that line.
Another way to execute it is as follows:
Assuming that the lines
x.sh
y.sh
were in a file called:
input.txt
We could execute
cat input.txt | while read file
do source ~/unwe/"$file"
done
The here doc makes things more interactive but the above example may allow you to understand it better.
answered Feb 7 at 15:21
Raman Sailopal
1,18117
1,18117
1
This other way is not equivalent to the original because the sourcing may happen in a subshell.
â Michael Homer
Feb 7 at 18:51
add a comment |Â
1
This other way is not equivalent to the original because the sourcing may happen in a subshell.
â Michael Homer
Feb 7 at 18:51
1
1
This other way is not equivalent to the original because the sourcing may happen in a subshell.
â Michael Homer
Feb 7 at 18:51
This other way is not equivalent to the original because the sourcing may happen in a subshell.
â Michael Homer
Feb 7 at 18:51
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f422557%2fa-while-loop-and-an-here-document-what-happens-when%23new-answer', 'question_page');
);
Post as a guest
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
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
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