How to read complete line in 'for' loop with spaces












105














I am trying to run a for loop for file and I want to display whole line.
But instead its displaying last word only. I want the complete line.



for j in `cat ./file_wget_med`

do
echo $j

done


result after run:



Found.


Here is my data:



$ cat file_wget_med
2013-09-11 14:27:03 ERROR 404: Not Found.









share|improve this question
























  • related: stackoverflow.com/questions/9084257/…
    – Ciro Santilli 新疆改造中心 六四事件 法轮功
    Apr 21 '18 at 8:28


















105














I am trying to run a for loop for file and I want to display whole line.
But instead its displaying last word only. I want the complete line.



for j in `cat ./file_wget_med`

do
echo $j

done


result after run:



Found.


Here is my data:



$ cat file_wget_med
2013-09-11 14:27:03 ERROR 404: Not Found.









share|improve this question
























  • related: stackoverflow.com/questions/9084257/…
    – Ciro Santilli 新疆改造中心 六四事件 法轮功
    Apr 21 '18 at 8:28
















105












105








105


39





I am trying to run a for loop for file and I want to display whole line.
But instead its displaying last word only. I want the complete line.



for j in `cat ./file_wget_med`

do
echo $j

done


result after run:



Found.


Here is my data:



$ cat file_wget_med
2013-09-11 14:27:03 ERROR 404: Not Found.









share|improve this question















I am trying to run a for loop for file and I want to display whole line.
But instead its displaying last word only. I want the complete line.



for j in `cat ./file_wget_med`

do
echo $j

done


result after run:



Found.


Here is my data:



$ cat file_wget_med
2013-09-11 14:27:03 ERROR 404: Not Found.






command-line bash scripts






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Sep 11 '13 at 19:59









Radu Rădeanu

116k34246322




116k34246322










asked Sep 11 '13 at 19:49









user192118

526253




526253












  • related: stackoverflow.com/questions/9084257/…
    – Ciro Santilli 新疆改造中心 六四事件 法轮功
    Apr 21 '18 at 8:28




















  • related: stackoverflow.com/questions/9084257/…
    – Ciro Santilli 新疆改造中心 六四事件 法轮功
    Apr 21 '18 at 8:28


















related: stackoverflow.com/questions/9084257/…
– Ciro Santilli 新疆改造中心 六四事件 法轮功
Apr 21 '18 at 8:28






related: stackoverflow.com/questions/9084257/…
– Ciro Santilli 新疆改造中心 六四事件 法轮功
Apr 21 '18 at 8:28












6 Answers
6






active

oldest

votes


















146














for loop splits when it sees any whitespace like space, tab, or newline. So, you should use IFS (Internal Field Separator):



IFS=$'n'       # make newlines the only separator
for j in $(cat ./file_wget_med)
do
echo "$j"
done





share|improve this answer



















  • 4




    And put care about single quotes on IFS because IFS=$"n" will split also "nn" strings. I found set IFS more reliable than use more complicated syntax or functions.
    – erm3nda
    Aug 25 '15 at 4:08






  • 19




    apparently it is advised to unset IFS afterwards, so that other commands are not influenced in this same shell.
    – Boris Däppen
    Oct 8 '15 at 14:49






  • 2




    What does the $ mean in IFS=$'n'?
    – Ren
    Dec 4 '16 at 8:02






  • 1




    $ makes line breaks work inside the string. This should also be done with local IFS=$'n' inside a function.
    – Andy Ray
    Mar 3 '17 at 18:34






  • 1




    @Renn that's $'...' known "ANSI-C Quoting"
    – αғsнιη
    Jun 7 '18 at 16:43



















73














for loops split on any whitespace (space, tab, newline) by default; the easiest way to work on one line at a time is to use a while read loop instead, which splits on newlines:



while read i; do echo "$i"; done < ./file_wget_med


I would expect your command to spit out one word per line (that's what happened when I tested it out with a file of my own). If something else is happening, I'm not sure what could be causing it.






share|improve this answer

















  • 5




    This is also a good alternative to for i in `ls`; do echo $1; done, by piping the output to the while command: ls|while read i; do echo $i; done. This works on file/folder names with spaces, without needing to change environment variables. Very good answer.
    – jishi
    Jun 1 '15 at 21:23












  • the while didn't handle the first and last lines very, not as well as the for loop with IFS
    – grantbow
    Jul 28 '15 at 15:16










  • @jishi Since it's primarily designed for display, and is responsive to terminal-window size and such, ls is not considered safe for use with | (the pipe operator). find is more flexible in addition to being safer for this purpose.
    – SeldomNeedy
    Nov 20 '15 at 21:48








  • 2




    This is a GREAT answer, I used it to turn a list I had into PLIST entries for an IOS app I was developing on mac OSX. I replaced the file input by piping the clipboad using pbpaste -> pbpaste | while read t; do echo "<string>$t</string>"; done
    – Big Rich
    Mar 8 '16 at 15:43








  • 2




    ls -1 may be used with | to guarantee one-per-line unformatted output
    – AndreyS Scherbakov
    May 7 '16 at 0:08



















19














#!/bin/bash
files=`find <subdir> -name '*'`
while read -r fname; do
echo $fname
done <<< "$files"


Verified working, not the one liner you probably want but it's not possible to do so elegantly.






share|improve this answer

















  • 1




    a here-string! most elegant of all other solutions IMO
    – Eliran Malka
    Jan 25 '17 at 22:20



















4














Here is a slight extension to Mitchell Currie's answer, that I like because of the small scope of side effects, which avoids having to set a variable:



#!/bin/bash
while read -r fname; do
echo $fname
done <<< "`find <subdir>`"





share|improve this answer



















  • 1




    You could remove -name '*' and it would be the same, no?
    – wjandrea
    Dec 29 '18 at 20:24












  • Yea I think you're right. I will remove the -name part
    – Dandalf
    9 hours ago



















0














I would write it like this:



cat ./file_wget_med | while read -r j
do
echo $j
done


as it requires least changes in the original script (except for the solution using IFS, but it modifies bash behavior not only for this loop control statement).






share|improve this answer





















  • Pipe and cat are unnecessary here. while loop accepts redirection just fine, which is why this is usually written as while IFS= read -r line; do...done < input.txt
    – Sergiy Kolodyazhnyy
    Dec 31 '18 at 5:14



















-1














Dandalf got real close to a functional solution, but one should NOT EVER be trying to assign the result of unknown amounts of input (i.e. find ~/.gdfuse -name '*') to variables! Or, at least be trying to do such a thing via an array variable; if you insist on being so lazy! So, here's Dandalf's solution done without the dangerous maneuver; and in all in one line



while read -r fname; do
echo $fname;
done <<< `find ~/.gdfuse -name '*'





share|improve this answer























  • Hey @odoncaoa , I tried to do the find command without the double quotes, but it makes all of the results appear as one line. I am confused about the "unknown amounts of input" with this command and the dangers involved. Can you provide an example of the dangers and how they could theoretically happen? I seriously do not desire to be lazy about it, I am just more comfortable in other programming languages.
    – Dandalf
    9 hours ago












protected by Sergiy Kolodyazhnyy Dec 31 '18 at 5:13



Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



Would you like to answer one of these unanswered questions instead?














6 Answers
6






active

oldest

votes








6 Answers
6






active

oldest

votes









active

oldest

votes






active

oldest

votes









146














for loop splits when it sees any whitespace like space, tab, or newline. So, you should use IFS (Internal Field Separator):



IFS=$'n'       # make newlines the only separator
for j in $(cat ./file_wget_med)
do
echo "$j"
done





share|improve this answer



















  • 4




    And put care about single quotes on IFS because IFS=$"n" will split also "nn" strings. I found set IFS more reliable than use more complicated syntax or functions.
    – erm3nda
    Aug 25 '15 at 4:08






  • 19




    apparently it is advised to unset IFS afterwards, so that other commands are not influenced in this same shell.
    – Boris Däppen
    Oct 8 '15 at 14:49






  • 2




    What does the $ mean in IFS=$'n'?
    – Ren
    Dec 4 '16 at 8:02






  • 1




    $ makes line breaks work inside the string. This should also be done with local IFS=$'n' inside a function.
    – Andy Ray
    Mar 3 '17 at 18:34






  • 1




    @Renn that's $'...' known "ANSI-C Quoting"
    – αғsнιη
    Jun 7 '18 at 16:43
















146














for loop splits when it sees any whitespace like space, tab, or newline. So, you should use IFS (Internal Field Separator):



IFS=$'n'       # make newlines the only separator
for j in $(cat ./file_wget_med)
do
echo "$j"
done





share|improve this answer



















  • 4




    And put care about single quotes on IFS because IFS=$"n" will split also "nn" strings. I found set IFS more reliable than use more complicated syntax or functions.
    – erm3nda
    Aug 25 '15 at 4:08






  • 19




    apparently it is advised to unset IFS afterwards, so that other commands are not influenced in this same shell.
    – Boris Däppen
    Oct 8 '15 at 14:49






  • 2




    What does the $ mean in IFS=$'n'?
    – Ren
    Dec 4 '16 at 8:02






  • 1




    $ makes line breaks work inside the string. This should also be done with local IFS=$'n' inside a function.
    – Andy Ray
    Mar 3 '17 at 18:34






  • 1




    @Renn that's $'...' known "ANSI-C Quoting"
    – αғsнιη
    Jun 7 '18 at 16:43














146












146








146






for loop splits when it sees any whitespace like space, tab, or newline. So, you should use IFS (Internal Field Separator):



IFS=$'n'       # make newlines the only separator
for j in $(cat ./file_wget_med)
do
echo "$j"
done





share|improve this answer














for loop splits when it sees any whitespace like space, tab, or newline. So, you should use IFS (Internal Field Separator):



IFS=$'n'       # make newlines the only separator
for j in $(cat ./file_wget_med)
do
echo "$j"
done






share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 13 '17 at 12:37









Community

1




1










answered Sep 11 '13 at 20:26









Radu Rădeanu

116k34246322




116k34246322








  • 4




    And put care about single quotes on IFS because IFS=$"n" will split also "nn" strings. I found set IFS more reliable than use more complicated syntax or functions.
    – erm3nda
    Aug 25 '15 at 4:08






  • 19




    apparently it is advised to unset IFS afterwards, so that other commands are not influenced in this same shell.
    – Boris Däppen
    Oct 8 '15 at 14:49






  • 2




    What does the $ mean in IFS=$'n'?
    – Ren
    Dec 4 '16 at 8:02






  • 1




    $ makes line breaks work inside the string. This should also be done with local IFS=$'n' inside a function.
    – Andy Ray
    Mar 3 '17 at 18:34






  • 1




    @Renn that's $'...' known "ANSI-C Quoting"
    – αғsнιη
    Jun 7 '18 at 16:43














  • 4




    And put care about single quotes on IFS because IFS=$"n" will split also "nn" strings. I found set IFS more reliable than use more complicated syntax or functions.
    – erm3nda
    Aug 25 '15 at 4:08






  • 19




    apparently it is advised to unset IFS afterwards, so that other commands are not influenced in this same shell.
    – Boris Däppen
    Oct 8 '15 at 14:49






  • 2




    What does the $ mean in IFS=$'n'?
    – Ren
    Dec 4 '16 at 8:02






  • 1




    $ makes line breaks work inside the string. This should also be done with local IFS=$'n' inside a function.
    – Andy Ray
    Mar 3 '17 at 18:34






  • 1




    @Renn that's $'...' known "ANSI-C Quoting"
    – αғsнιη
    Jun 7 '18 at 16:43








4




4




And put care about single quotes on IFS because IFS=$"n" will split also "nn" strings. I found set IFS more reliable than use more complicated syntax or functions.
– erm3nda
Aug 25 '15 at 4:08




And put care about single quotes on IFS because IFS=$"n" will split also "nn" strings. I found set IFS more reliable than use more complicated syntax or functions.
– erm3nda
Aug 25 '15 at 4:08




19




19




apparently it is advised to unset IFS afterwards, so that other commands are not influenced in this same shell.
– Boris Däppen
Oct 8 '15 at 14:49




apparently it is advised to unset IFS afterwards, so that other commands are not influenced in this same shell.
– Boris Däppen
Oct 8 '15 at 14:49




2




2




What does the $ mean in IFS=$'n'?
– Ren
Dec 4 '16 at 8:02




What does the $ mean in IFS=$'n'?
– Ren
Dec 4 '16 at 8:02




1




1




$ makes line breaks work inside the string. This should also be done with local IFS=$'n' inside a function.
– Andy Ray
Mar 3 '17 at 18:34




$ makes line breaks work inside the string. This should also be done with local IFS=$'n' inside a function.
– Andy Ray
Mar 3 '17 at 18:34




1




1




@Renn that's $'...' known "ANSI-C Quoting"
– αғsнιη
Jun 7 '18 at 16:43




@Renn that's $'...' known "ANSI-C Quoting"
– αғsнιη
Jun 7 '18 at 16:43













73














for loops split on any whitespace (space, tab, newline) by default; the easiest way to work on one line at a time is to use a while read loop instead, which splits on newlines:



while read i; do echo "$i"; done < ./file_wget_med


I would expect your command to spit out one word per line (that's what happened when I tested it out with a file of my own). If something else is happening, I'm not sure what could be causing it.






share|improve this answer

















  • 5




    This is also a good alternative to for i in `ls`; do echo $1; done, by piping the output to the while command: ls|while read i; do echo $i; done. This works on file/folder names with spaces, without needing to change environment variables. Very good answer.
    – jishi
    Jun 1 '15 at 21:23












  • the while didn't handle the first and last lines very, not as well as the for loop with IFS
    – grantbow
    Jul 28 '15 at 15:16










  • @jishi Since it's primarily designed for display, and is responsive to terminal-window size and such, ls is not considered safe for use with | (the pipe operator). find is more flexible in addition to being safer for this purpose.
    – SeldomNeedy
    Nov 20 '15 at 21:48








  • 2




    This is a GREAT answer, I used it to turn a list I had into PLIST entries for an IOS app I was developing on mac OSX. I replaced the file input by piping the clipboad using pbpaste -> pbpaste | while read t; do echo "<string>$t</string>"; done
    – Big Rich
    Mar 8 '16 at 15:43








  • 2




    ls -1 may be used with | to guarantee one-per-line unformatted output
    – AndreyS Scherbakov
    May 7 '16 at 0:08
















73














for loops split on any whitespace (space, tab, newline) by default; the easiest way to work on one line at a time is to use a while read loop instead, which splits on newlines:



while read i; do echo "$i"; done < ./file_wget_med


I would expect your command to spit out one word per line (that's what happened when I tested it out with a file of my own). If something else is happening, I'm not sure what could be causing it.






share|improve this answer

















  • 5




    This is also a good alternative to for i in `ls`; do echo $1; done, by piping the output to the while command: ls|while read i; do echo $i; done. This works on file/folder names with spaces, without needing to change environment variables. Very good answer.
    – jishi
    Jun 1 '15 at 21:23












  • the while didn't handle the first and last lines very, not as well as the for loop with IFS
    – grantbow
    Jul 28 '15 at 15:16










  • @jishi Since it's primarily designed for display, and is responsive to terminal-window size and such, ls is not considered safe for use with | (the pipe operator). find is more flexible in addition to being safer for this purpose.
    – SeldomNeedy
    Nov 20 '15 at 21:48








  • 2




    This is a GREAT answer, I used it to turn a list I had into PLIST entries for an IOS app I was developing on mac OSX. I replaced the file input by piping the clipboad using pbpaste -> pbpaste | while read t; do echo "<string>$t</string>"; done
    – Big Rich
    Mar 8 '16 at 15:43








  • 2




    ls -1 may be used with | to guarantee one-per-line unformatted output
    – AndreyS Scherbakov
    May 7 '16 at 0:08














73












73








73






for loops split on any whitespace (space, tab, newline) by default; the easiest way to work on one line at a time is to use a while read loop instead, which splits on newlines:



while read i; do echo "$i"; done < ./file_wget_med


I would expect your command to spit out one word per line (that's what happened when I tested it out with a file of my own). If something else is happening, I'm not sure what could be causing it.






share|improve this answer












for loops split on any whitespace (space, tab, newline) by default; the easiest way to work on one line at a time is to use a while read loop instead, which splits on newlines:



while read i; do echo "$i"; done < ./file_wget_med


I would expect your command to spit out one word per line (that's what happened when I tested it out with a file of my own). If something else is happening, I'm not sure what could be causing it.







share|improve this answer












share|improve this answer



share|improve this answer










answered Sep 11 '13 at 20:04









evilsoup

3,3591322




3,3591322








  • 5




    This is also a good alternative to for i in `ls`; do echo $1; done, by piping the output to the while command: ls|while read i; do echo $i; done. This works on file/folder names with spaces, without needing to change environment variables. Very good answer.
    – jishi
    Jun 1 '15 at 21:23












  • the while didn't handle the first and last lines very, not as well as the for loop with IFS
    – grantbow
    Jul 28 '15 at 15:16










  • @jishi Since it's primarily designed for display, and is responsive to terminal-window size and such, ls is not considered safe for use with | (the pipe operator). find is more flexible in addition to being safer for this purpose.
    – SeldomNeedy
    Nov 20 '15 at 21:48








  • 2




    This is a GREAT answer, I used it to turn a list I had into PLIST entries for an IOS app I was developing on mac OSX. I replaced the file input by piping the clipboad using pbpaste -> pbpaste | while read t; do echo "<string>$t</string>"; done
    – Big Rich
    Mar 8 '16 at 15:43








  • 2




    ls -1 may be used with | to guarantee one-per-line unformatted output
    – AndreyS Scherbakov
    May 7 '16 at 0:08














  • 5




    This is also a good alternative to for i in `ls`; do echo $1; done, by piping the output to the while command: ls|while read i; do echo $i; done. This works on file/folder names with spaces, without needing to change environment variables. Very good answer.
    – jishi
    Jun 1 '15 at 21:23












  • the while didn't handle the first and last lines very, not as well as the for loop with IFS
    – grantbow
    Jul 28 '15 at 15:16










  • @jishi Since it's primarily designed for display, and is responsive to terminal-window size and such, ls is not considered safe for use with | (the pipe operator). find is more flexible in addition to being safer for this purpose.
    – SeldomNeedy
    Nov 20 '15 at 21:48








  • 2




    This is a GREAT answer, I used it to turn a list I had into PLIST entries for an IOS app I was developing on mac OSX. I replaced the file input by piping the clipboad using pbpaste -> pbpaste | while read t; do echo "<string>$t</string>"; done
    – Big Rich
    Mar 8 '16 at 15:43








  • 2




    ls -1 may be used with | to guarantee one-per-line unformatted output
    – AndreyS Scherbakov
    May 7 '16 at 0:08








5




5




This is also a good alternative to for i in `ls`; do echo $1; done, by piping the output to the while command: ls|while read i; do echo $i; done. This works on file/folder names with spaces, without needing to change environment variables. Very good answer.
– jishi
Jun 1 '15 at 21:23






This is also a good alternative to for i in `ls`; do echo $1; done, by piping the output to the while command: ls|while read i; do echo $i; done. This works on file/folder names with spaces, without needing to change environment variables. Very good answer.
– jishi
Jun 1 '15 at 21:23














the while didn't handle the first and last lines very, not as well as the for loop with IFS
– grantbow
Jul 28 '15 at 15:16




the while didn't handle the first and last lines very, not as well as the for loop with IFS
– grantbow
Jul 28 '15 at 15:16












@jishi Since it's primarily designed for display, and is responsive to terminal-window size and such, ls is not considered safe for use with | (the pipe operator). find is more flexible in addition to being safer for this purpose.
– SeldomNeedy
Nov 20 '15 at 21:48






@jishi Since it's primarily designed for display, and is responsive to terminal-window size and such, ls is not considered safe for use with | (the pipe operator). find is more flexible in addition to being safer for this purpose.
– SeldomNeedy
Nov 20 '15 at 21:48






2




2




This is a GREAT answer, I used it to turn a list I had into PLIST entries for an IOS app I was developing on mac OSX. I replaced the file input by piping the clipboad using pbpaste -> pbpaste | while read t; do echo "<string>$t</string>"; done
– Big Rich
Mar 8 '16 at 15:43






This is a GREAT answer, I used it to turn a list I had into PLIST entries for an IOS app I was developing on mac OSX. I replaced the file input by piping the clipboad using pbpaste -> pbpaste | while read t; do echo "<string>$t</string>"; done
– Big Rich
Mar 8 '16 at 15:43






2




2




ls -1 may be used with | to guarantee one-per-line unformatted output
– AndreyS Scherbakov
May 7 '16 at 0:08




ls -1 may be used with | to guarantee one-per-line unformatted output
– AndreyS Scherbakov
May 7 '16 at 0:08











19














#!/bin/bash
files=`find <subdir> -name '*'`
while read -r fname; do
echo $fname
done <<< "$files"


Verified working, not the one liner you probably want but it's not possible to do so elegantly.






share|improve this answer

















  • 1




    a here-string! most elegant of all other solutions IMO
    – Eliran Malka
    Jan 25 '17 at 22:20
















19














#!/bin/bash
files=`find <subdir> -name '*'`
while read -r fname; do
echo $fname
done <<< "$files"


Verified working, not the one liner you probably want but it's not possible to do so elegantly.






share|improve this answer

















  • 1




    a here-string! most elegant of all other solutions IMO
    – Eliran Malka
    Jan 25 '17 at 22:20














19












19








19






#!/bin/bash
files=`find <subdir> -name '*'`
while read -r fname; do
echo $fname
done <<< "$files"


Verified working, not the one liner you probably want but it's not possible to do so elegantly.






share|improve this answer












#!/bin/bash
files=`find <subdir> -name '*'`
while read -r fname; do
echo $fname
done <<< "$files"


Verified working, not the one liner you probably want but it's not possible to do so elegantly.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 2 '16 at 6:34









Mitchell Currie

29124




29124








  • 1




    a here-string! most elegant of all other solutions IMO
    – Eliran Malka
    Jan 25 '17 at 22:20














  • 1




    a here-string! most elegant of all other solutions IMO
    – Eliran Malka
    Jan 25 '17 at 22:20








1




1




a here-string! most elegant of all other solutions IMO
– Eliran Malka
Jan 25 '17 at 22:20




a here-string! most elegant of all other solutions IMO
– Eliran Malka
Jan 25 '17 at 22:20











4














Here is a slight extension to Mitchell Currie's answer, that I like because of the small scope of side effects, which avoids having to set a variable:



#!/bin/bash
while read -r fname; do
echo $fname
done <<< "`find <subdir>`"





share|improve this answer



















  • 1




    You could remove -name '*' and it would be the same, no?
    – wjandrea
    Dec 29 '18 at 20:24












  • Yea I think you're right. I will remove the -name part
    – Dandalf
    9 hours ago
















4














Here is a slight extension to Mitchell Currie's answer, that I like because of the small scope of side effects, which avoids having to set a variable:



#!/bin/bash
while read -r fname; do
echo $fname
done <<< "`find <subdir>`"





share|improve this answer



















  • 1




    You could remove -name '*' and it would be the same, no?
    – wjandrea
    Dec 29 '18 at 20:24












  • Yea I think you're right. I will remove the -name part
    – Dandalf
    9 hours ago














4












4








4






Here is a slight extension to Mitchell Currie's answer, that I like because of the small scope of side effects, which avoids having to set a variable:



#!/bin/bash
while read -r fname; do
echo $fname
done <<< "`find <subdir>`"





share|improve this answer














Here is a slight extension to Mitchell Currie's answer, that I like because of the small scope of side effects, which avoids having to set a variable:



#!/bin/bash
while read -r fname; do
echo $fname
done <<< "`find <subdir>`"






share|improve this answer














share|improve this answer



share|improve this answer








edited 9 hours ago

























answered Jun 7 '18 at 15:57









Dandalf

1414




1414








  • 1




    You could remove -name '*' and it would be the same, no?
    – wjandrea
    Dec 29 '18 at 20:24












  • Yea I think you're right. I will remove the -name part
    – Dandalf
    9 hours ago














  • 1




    You could remove -name '*' and it would be the same, no?
    – wjandrea
    Dec 29 '18 at 20:24












  • Yea I think you're right. I will remove the -name part
    – Dandalf
    9 hours ago








1




1




You could remove -name '*' and it would be the same, no?
– wjandrea
Dec 29 '18 at 20:24






You could remove -name '*' and it would be the same, no?
– wjandrea
Dec 29 '18 at 20:24














Yea I think you're right. I will remove the -name part
– Dandalf
9 hours ago




Yea I think you're right. I will remove the -name part
– Dandalf
9 hours ago











0














I would write it like this:



cat ./file_wget_med | while read -r j
do
echo $j
done


as it requires least changes in the original script (except for the solution using IFS, but it modifies bash behavior not only for this loop control statement).






share|improve this answer





















  • Pipe and cat are unnecessary here. while loop accepts redirection just fine, which is why this is usually written as while IFS= read -r line; do...done < input.txt
    – Sergiy Kolodyazhnyy
    Dec 31 '18 at 5:14
















0














I would write it like this:



cat ./file_wget_med | while read -r j
do
echo $j
done


as it requires least changes in the original script (except for the solution using IFS, but it modifies bash behavior not only for this loop control statement).






share|improve this answer





















  • Pipe and cat are unnecessary here. while loop accepts redirection just fine, which is why this is usually written as while IFS= read -r line; do...done < input.txt
    – Sergiy Kolodyazhnyy
    Dec 31 '18 at 5:14














0












0








0






I would write it like this:



cat ./file_wget_med | while read -r j
do
echo $j
done


as it requires least changes in the original script (except for the solution using IFS, but it modifies bash behavior not only for this loop control statement).






share|improve this answer












I would write it like this:



cat ./file_wget_med | while read -r j
do
echo $j
done


as it requires least changes in the original script (except for the solution using IFS, but it modifies bash behavior not only for this loop control statement).







share|improve this answer












share|improve this answer



share|improve this answer










answered Aug 27 '18 at 7:19









mik

1011




1011












  • Pipe and cat are unnecessary here. while loop accepts redirection just fine, which is why this is usually written as while IFS= read -r line; do...done < input.txt
    – Sergiy Kolodyazhnyy
    Dec 31 '18 at 5:14


















  • Pipe and cat are unnecessary here. while loop accepts redirection just fine, which is why this is usually written as while IFS= read -r line; do...done < input.txt
    – Sergiy Kolodyazhnyy
    Dec 31 '18 at 5:14
















Pipe and cat are unnecessary here. while loop accepts redirection just fine, which is why this is usually written as while IFS= read -r line; do...done < input.txt
– Sergiy Kolodyazhnyy
Dec 31 '18 at 5:14




Pipe and cat are unnecessary here. while loop accepts redirection just fine, which is why this is usually written as while IFS= read -r line; do...done < input.txt
– Sergiy Kolodyazhnyy
Dec 31 '18 at 5:14











-1














Dandalf got real close to a functional solution, but one should NOT EVER be trying to assign the result of unknown amounts of input (i.e. find ~/.gdfuse -name '*') to variables! Or, at least be trying to do such a thing via an array variable; if you insist on being so lazy! So, here's Dandalf's solution done without the dangerous maneuver; and in all in one line



while read -r fname; do
echo $fname;
done <<< `find ~/.gdfuse -name '*'





share|improve this answer























  • Hey @odoncaoa , I tried to do the find command without the double quotes, but it makes all of the results appear as one line. I am confused about the "unknown amounts of input" with this command and the dangers involved. Can you provide an example of the dangers and how they could theoretically happen? I seriously do not desire to be lazy about it, I am just more comfortable in other programming languages.
    – Dandalf
    9 hours ago


















-1














Dandalf got real close to a functional solution, but one should NOT EVER be trying to assign the result of unknown amounts of input (i.e. find ~/.gdfuse -name '*') to variables! Or, at least be trying to do such a thing via an array variable; if you insist on being so lazy! So, here's Dandalf's solution done without the dangerous maneuver; and in all in one line



while read -r fname; do
echo $fname;
done <<< `find ~/.gdfuse -name '*'





share|improve this answer























  • Hey @odoncaoa , I tried to do the find command without the double quotes, but it makes all of the results appear as one line. I am confused about the "unknown amounts of input" with this command and the dangers involved. Can you provide an example of the dangers and how they could theoretically happen? I seriously do not desire to be lazy about it, I am just more comfortable in other programming languages.
    – Dandalf
    9 hours ago
















-1












-1








-1






Dandalf got real close to a functional solution, but one should NOT EVER be trying to assign the result of unknown amounts of input (i.e. find ~/.gdfuse -name '*') to variables! Or, at least be trying to do such a thing via an array variable; if you insist on being so lazy! So, here's Dandalf's solution done without the dangerous maneuver; and in all in one line



while read -r fname; do
echo $fname;
done <<< `find ~/.gdfuse -name '*'





share|improve this answer














Dandalf got real close to a functional solution, but one should NOT EVER be trying to assign the result of unknown amounts of input (i.e. find ~/.gdfuse -name '*') to variables! Or, at least be trying to do such a thing via an array variable; if you insist on being so lazy! So, here's Dandalf's solution done without the dangerous maneuver; and in all in one line



while read -r fname; do
echo $fname;
done <<< `find ~/.gdfuse -name '*'






share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 30 '18 at 23:03









Pablo Bianchi

2,3771528




2,3771528










answered Dec 29 '18 at 19:41









odoncaoa

293




293












  • Hey @odoncaoa , I tried to do the find command without the double quotes, but it makes all of the results appear as one line. I am confused about the "unknown amounts of input" with this command and the dangers involved. Can you provide an example of the dangers and how they could theoretically happen? I seriously do not desire to be lazy about it, I am just more comfortable in other programming languages.
    – Dandalf
    9 hours ago




















  • Hey @odoncaoa , I tried to do the find command without the double quotes, but it makes all of the results appear as one line. I am confused about the "unknown amounts of input" with this command and the dangers involved. Can you provide an example of the dangers and how they could theoretically happen? I seriously do not desire to be lazy about it, I am just more comfortable in other programming languages.
    – Dandalf
    9 hours ago


















Hey @odoncaoa , I tried to do the find command without the double quotes, but it makes all of the results appear as one line. I am confused about the "unknown amounts of input" with this command and the dangers involved. Can you provide an example of the dangers and how they could theoretically happen? I seriously do not desire to be lazy about it, I am just more comfortable in other programming languages.
– Dandalf
9 hours ago






Hey @odoncaoa , I tried to do the find command without the double quotes, but it makes all of the results appear as one line. I am confused about the "unknown amounts of input" with this command and the dangers involved. Can you provide an example of the dangers and how they could theoretically happen? I seriously do not desire to be lazy about it, I am just more comfortable in other programming languages.
– Dandalf
9 hours ago







protected by Sergiy Kolodyazhnyy Dec 31 '18 at 5:13



Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



Would you like to answer one of these unanswered questions instead?



Popular posts from this blog

Human spaceflight

Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

張江高科駅