Fixing stdin inside a redirected loop...

In this group, it is an FGA that one should so: commandThatGeneratesTheFilenames | while read x ... instead of the more common: for i in ... because of the problems of filenames that spaces and other weird characters. However, one downside to the "while" method is that inside the loop, stdin is now coming from the pipe, and commands that we execute inside the loop, that expect a normal stdin, will misbehave. Workarounds: 1) append "< /dev/tty" to each command 2) enclose the commands in parens and redirect that. I.e.: commandThatGeneratesTheFilenames | while read x;do (cmd1;cmd2;cmd3;...) < /dev/tty done Method 2 is nice and seems to work fine, but I am wondering if there is any hidden cost to it and if there is any more elegant/effcient way to do this. -- Just for a change of pace, this sig is *not* an obscure reference to comp.lang.c...

Kenny McCormack wrote: > In this group, it is an FGA that one should so: > > commandThatGeneratesTheFilenames | while read x ... > > instead of the more common: > > for i in ... > > because of the problems of filenames that spaces and other weird > characters. > > However, one downside to the "while" method is that inside the loop, > stdin is now coming from the pipe, and commands that we execute inside > the loop, that expect a normal stdin, will misbehave. > > Workarounds: > 1) append "< /dev/tty" to each command > 2) enclose the commands in parens and redirect that. I.e.: > > commandThatGeneratesTheFilenames | while read x;do > (cmd1;cmd2;cmd3;...) < /dev/tty > done I think (at least with bash) it's possible to use a file descriptor other than the standard ones, and use read -u to read from that descriptor. This way, standard descriptors (0, 1 and 2) inside the loop are not affected. Something like exec 3< <(command) while read -u 3 line; do # unaffected commands here... done exec 3>&- I understand it's a highly nonstandard solution, but, depending on where it has to run, it might be applicable.

In article <i246br$vjs$1@speranza.aioe.org>, pk <pk@pk.invalid> wrote: .... >I think (at least with bash) it's possible to use a file descriptor other >than the standard ones, and use read -u to read from that descriptor. This >way, standard descriptors (0, 1 and 2) inside the loop are not affected. > >Something like > >exec 3< <(command) > >while read -u 3 line; do > # unaffected commands here... >done > >exec 3>&- > >I understand it's a highly nonstandard solution, but, depending on where it >has to run, it might be applicable. Very interesting. As readers of my posts know, I'm not a "standards jockey", so don't take what I say next as the typical SJ jockeying... That said, 1) The above works if I invoke "bash" as "bash". 2) (However) It does not work if I invoke "bash" as "sh" 3) It doesn't work under "dash" (which is what /bin/sh on some Linux boxes actually is). Anyway, as I said, it is quite intriguing. -- Just for a change of pace, this sig is *not* an obscure reference to comp.lang.c...

In article <i24at9$rc5$1@news.xmission.com>, Kenny McCormack <gazelle@shell.xmission.com> wrote: .... >That said, > 1) The above works if I invoke "bash" as "bash". > 2) (However) It does not work if I invoke "bash" as "sh" > 3) It doesn't work under "dash" (which is what /bin/sh on some Linux > boxes actually is). > >Anyway, as I said, it is quite intriguing. I forgot to add, the important thing, which is that your solution, unfortunately, does not work on the targetted system (which is a Linux system without bash - yes, they exist). So, I am still curious about the questions raised in the OP - is there any hidden cost (inefficiency) to using the ()</dev/tty method, and are there any (other) alternatives? -- "We should always be disposed to believe that which appears to us to be white is really black, if the hierarchy of the church so decides." - Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

On Tue, 20 Jul 2010 14:12:57 +0000 (UTC) gazelle@shell.xmission.com (Kenny McCormack) wrote: > In article <i246br$vjs$1@speranza.aioe.org>, pk <pk@pk.invalid> wrote: > ... > >I think (at least with bash) it's possible to use a file descriptor > >other than the standard ones, and use read -u to read from that > >descriptor. This way, standard descriptors (0, 1 and 2) inside the loop > >are not affected. > > > >Something like > > > >exec 3< <(command) > > > >while read -u 3 line; do > > # unaffected commands here... > >done > > > >exec 3>&- > > > >I understand it's a highly nonstandard solution, but, depending on where > >it has to run, it might be applicable. > > Very interesting. As readers of my posts know, I'm not a "standards > jockey", so don't take what I say next as the typical SJ jockeying... > > That said, > 1) The above works if I invoke "bash" as "bash". > 2) (However) It does not work if I invoke "bash" as "sh" > 3) It doesn't work under "dash" (which is what /bin/sh on some Linux > boxes actually is). Standards jockey or not, if that is where it has to run, you definitely need a standard solution.

Kenny McCormack wrote: > In this group, it is an FGA that one should so: > > commandThatGeneratesTheFilenames | while read x ... > > instead of the more common: > > for i in ... > > because of the problems of filenames that spaces and other weird > characters. No, the foregone assumption (FGA is not a common Usenet acronym -- shouldn't that be "foregone conclusion" anyway?) is that find(1) with `-exec', or `find' with xargs(1), are safer than both approaches. Usenet rule of thumb: Never ask what is better; bottom line is that better is what works for you. Ask instead what is more efficient aso. given a specific context. -- PointedEars

In article <i243tu$l8g$1@news.xmission.com>, Kenny McCormack <gazelle@shell.xmission.com> wrote: >In this group, it is an FGA that one should so: > > commandThatGeneratesTheFilenames | while read x ... > >instead of the more common: > > for i in ... > >because of the problems of filenames that spaces and other weird characters. > >However, one downside to the "while" method is that inside the loop, >stdin is now coming from the pipe, and commands that we execute inside >the loop, that expect a normal stdin, will misbehave. > >Workarounds: > 1) append "< /dev/tty" to each command > 2) enclose the commands in parens and redirect that. I.e.: > > commandThatGeneratesTheFilenames | while read x;do > (cmd1;cmd2;cmd3;...) < /dev/tty > done > >Method 2 is nice and seems to work fine, but I am wondering if there is >any hidden cost to it and if there is any more elegant/effcient way to >do this. Unless you specifically want to read from the controlling tty rather than the standard input, it's always better to save the standard input to another fd and then read from it. { commandThatGeneratesTheFilenames | while read x <&4; do cmd1 cmd2 cmd3 done 4<&0 0<&3 } 3<&0 In modern shells (ksh93/bash/zsh) you can do: while read -u3 x; do cmd1 cmd2 cmd3 done 3< <(commandThatGeneratesTheFilenames) John -- John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

In article <B_qdnbdAifw8u9rRnZ2dnUVZ_s6dnZ2d@speakeasy.net>, John DuBois <spcecdt@armory.com> wrote: .... > Unless you specifically want to read from the controlling tty rather than > the standard input, it's always better to save the standard input to > another fd and then read from it. > > { > commandThatGeneratesTheFilenames | > while read x <&4; do > cmd1 > cmd2 > cmd3 > done 4<&0 0<&3 > } 3<&0 What's the difference between enclosing the cmds in {} vs. ()? -- Faced with the choice between changing one's mind and proving that there is no need to do so, almost everyone gets busy on the proof. - John Kenneth Galbraith -

On 2010-07-21, Kenny McCormack wrote: > In article <B_qdnbdAifw8u9rRnZ2dnUVZ_s6dnZ2d@speakeasy.net>, > John DuBois <spcecdt@armory.com> wrote: > ... >> Unless you specifically want to read from the controlling tty rather than >> the standard input, it's always better to save the standard input to >> another fd and then read from it. >> >> { >> commandThatGeneratesTheFilenames | >> while read x <&4; do >> cmd1 >> cmd2 >> cmd3 >> done 4<&0 0<&3 >> } 3<&0 > > What's the difference between enclosing the cmds in {} vs. ()? Commands in ( ) are executed in a subshell. -- Chris F.A. Johnson, author <http://shell.cfajohnson.com/> =================================================================== Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)

In article <8aoumsFvcrU2@mid.individual.net>, Chris F.A. Johnson <cfajohnson@gmail.com> wrote: >On 2010-07-21, Kenny McCormack wrote: >> In article <B_qdnbdAifw8u9rRnZ2dnUVZ_s6dnZ2d@speakeasy.net>, >> John DuBois <spcecdt@armory.com> wrote: >> ... >>> Unless you specifically want to read from the controlling tty rather than >>> the standard input, it's always better to save the standard input to >>> another fd and then read from it. >>> >>> { >>> commandThatGeneratesTheFilenames | >>> while read x <&4; do >>> cmd1 >>> cmd2 >>> cmd3 >>> done 4<&0 0<&3 >>> } 3<&0 >> >> What's the difference between enclosing the cmds in {} vs. ()? > > Commands in ( ) are executed in a subshell. That's what I thought. So, the answer to the original question, despite all the other flurry, is simply: Yes, you should use {} rather than (). -- "We should always be disposed to believe that which appears to us to be white is really black, if the hierarchy of the church so decides." - Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

Kenny McCormack wrote: > Chris F.A. Johnson <cfajohnson@gmail.com> wrote: >> On 2010-07-21, Kenny McCormack wrote: >>> What's the difference between enclosing the cmds in {} vs. ()? >> Commands in ( ) are executed in a subshell. > > That's what I thought. So, the answer to the original question, despite > all the other flurry, is simply: Yes, you should use {} rather than (). No, the answer simply is, again, "it depends." That is the part of software development that you do not seem to understand. -- PointedEars

On 2010-07-21, John DuBois wrote: > In article <i243tu$l8g$1@news.xmission.com>, > Kenny McCormack <gazelle@shell.xmission.com> wrote: >>In this group, it is an FGA that one should so: >> >> commandThatGeneratesTheFilenames | while read x ... >> >>instead of the more common: >> >> for i in ... >> >>because of the problems of filenames that spaces and other weird characters. >> >>However, one downside to the "while" method is that inside the loop, >>stdin is now coming from the pipe, and commands that we execute inside >>the loop, that expect a normal stdin, will misbehave. >> >>Workarounds: >> 1) append "< /dev/tty" to each command >> 2) enclose the commands in parens and redirect that. I.e.: >> >> commandThatGeneratesTheFilenames | while read x;do >> (cmd1;cmd2;cmd3;...) < /dev/tty >> done >> >>Method 2 is nice and seems to work fine, but I am wondering if there is >>any hidden cost to it and if there is any more elegant/effcient way to >>do this. > > Unless you specifically want to read from the controlling tty rather than > the standard input, it's always better to save the standard input to > another fd and then read from it. Why? > { > commandThatGeneratesTheFilenames | > while read x <&4; do That will fail on filenames beginning or ending with spaces. while IFS= read -r x <&4 > cmd1 > cmd2 > cmd3 > done 4<&0 0<&3 > } 3<&0 > > In modern shells (ksh93/bash/zsh) you can do: > > while read -u3 x; do > cmd1 > cmd2 > cmd3 > done 3< <(commandThatGeneratesTheFilenames) > > John -- Chris F.A. Johnson, author <http://shell.cfajohnson.com/> =================================================================== Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)

In article <4540035.MirdbgypaU@PointedEars.de>, Thomas 'PointedEars' Lahn <usenet@PointedEars.de> wrote: >Kenny McCormack wrote: > >> Chris F.A. Johnson <cfajohnson@gmail.com> wrote: >>> On 2010-07-21, Kenny McCormack wrote: >>>> What's the difference between enclosing the cmds in {} vs. ()? >>> Commands in ( ) are executed in a subshell. >> >> That's what I thought. So, the answer to the original question, despite >> all the other flurry, is simply: Yes, you should use {} rather than (). > >No, the answer simply is, again, "it depends." That is the part of software >development that you do not seem to understand. You funny. (And I've not even seen any pix of you and you funny ears!) -- > No, I haven't, that's why I'm asking questions. If you won't help me, > why don't you just go find your lost manhood elsewhere. CLC in a nutshell.

On 2010-07-21, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote: > No, the foregone assumption (FGA is not a common Usenet acronym "Frequently Given Answer", used by some guy whose name I've forgotten to refer to things he maintains in a format chosen to prevent people from rebutting the idiocy therein. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Kenny McCormack wrote: > Thomas 'PointedEars' Lahn wrote: >> Kenny McCormack wrote: >>> Chris F.A. Johnson <cfajohnson@gmail.com> wrote: >>>> On 2010-07-21, Kenny McCormack wrote: >>>>> What's the difference between enclosing the cmds in {} vs. ()? >>>> Commands in ( ) are executed in a subshell. >>> That's what I thought. So, the answer to the original question, despite >>> all the other flurry, is simply: Yes, you should use {} rather than (). >> No, the answer simply is, again, "it depends." That is the part of >> software development that you do not seem to understand. > > You funny. It was not my intention to amuse you, but to make you think twice. BTW, in responding like this you are also making a fool of yourself with regard to grammar. > (And I've not even seen any pix of you and you funny ears!) I have not seen a photo of you either. So what? -- PointedEars

Seebs wrote: > Thomas 'PointedEars' Lahn wrote: >> No, the foregone assumption (FGA is not a common Usenet acronym > > "Frequently Given Answer", used by some guy whose name I've forgotten > to refer to things he maintains in a format chosen to prevent people from > rebutting the idiocy therein. Thanks. In ten years of regular Usenet participation, in and outside of the Big 8, I had never come across that acronym. It is not in the Jargon File either. So I doubt it is more than his original research. -- PointedEars

In article <8ap77sFvcrU3@mid.individual.net>, Chris F.A. Johnson <cfajohnson@gmail.com> wrote: >On 2010-07-21, John DuBois wrote: >> In article <i243tu$l8g$1@news.xmission.com>, >> Kenny McCormack <gazelle@shell.xmission.com> wrote: >>>Workarounds: >>> 1) append "< /dev/tty" to each command >>> 2) enclose the commands in parens and redirect that. I.e.: >>> >>> commandThatGeneratesTheFilenames | while read x;do >>> (cmd1;cmd2;cmd3;...) < /dev/tty >>> done >>> >>>Method 2 is nice and seems to work fine, but I am wondering if there is >>>any hidden cost to it and if there is any more elegant/effcient way to >>>do this. >> >> Unless you specifically want to read from the controlling tty rather than >> the standard input, it's always better to save the standard input to >> another fd and then read from it. > > Why? Because the standard input may not be the controlling tty (if the program is piped or redirected into, or started from an environment with no controlling tty, etc). John -- John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

2010-07-20, 12:13(+00), Kenny McCormack: > In this group, it is an FGA that one should so: > > commandThatGeneratesTheFilenames | while read x ... > > instead of the more common: > > for i in ... > > because of the problems of filenames that spaces and other weird characters. After IFS=' ' # NL set -f for i in $(commandThatGeneratesTheFilenames); do... shouldn't be a problem (except that the loop only starts when commandThatGeneratesTheFilenames finishes). Other solution (not any better either than the ones that have already been given): while IFS= read <&3 -r i; do ... done 3<<EOF $(commandThatGeneratesTheFilenames) EOF { commandThatGeneratesTheFilenames | while IFS= read <&3 -r i; do ... done 3<&0 <&4 4<&- } 4<&0 as already given would be the best one. If you're picky, you may write it: { commandThatGeneratesTheFilenames 4<&- | while IFS= read <&3 -r i; do { ... } 3<&- done 3<&0 <&4 4<&- } 4<&0 or: { commandThatGeneratesTheFilenames 4<&- | while IFS= read -r i 4<&-; do { ... } <&4 4<&- done } 4<&0 -- Stephane

while loop inside a for loop
Hi, can someone please tell me why "time" (t) is not updated correctly within the while loop? Please run this small code in your machine and you'll know what I'm taking about. What I want is: for t=1 run the "while loop" until iq<=(numberc-1) then t=2 run the "while loop" again until iq<=(numberc-1), and so on. Basically, this code runs through all the nonzero elements of A and attempts to divide them individually into two, once a certain time has passed. Please feel free to ask for clarifications. Many thanks in advance. A=[0 0 0 0 0 0 0 0 0 0 ...

Triple nested loop python (While loop insde of for loop inside of while loop)
try to make my triple nested loop working. My code would be: c = 4 y1 = [] m1 = [] std1 = [] while c <24: c = c + 1 a = [] f.seek(0,0) for columns in ( raw.strip().split() for raw in f ): a.append(columns[c]) x = np.array(a, float) not_nan = np.logical_not(np.isnan(x)) indices = np.arange(len(x)) interp = interp1d(indices[not_nan], x[not_nan], kind = 'nearest') p = interp(indices) N = len(p) dt ...

Re: i am having a problem with while loops, i have two while loops, i have a random number generator inside the "inside" loop and i want to read an array outside the "outer"
I think I have a similar problem - I have a while loop with Flat Sequence controlled for loop that produces output. This output needs to be displayed every while loop pass, but I get no output as the while loop feeds back thru a shift register and repeats all the innner funcions without sending the ouput to form new entries in the array.   Is there any way we could stop the while loop for a split second (but practically just for no time, so that no time is wasted when it outputs the data)?   Or is it a bad approach altogether?   Appreciate any advice.   kolo...

Re: i am having a problem with while loops, i have two while loops, i have a random number generator inside the "inside" loop and i want to read an array outside the "outer" #2
Hi guys, Apologies about he messy thread - I needed asolution urgently and I didn't get a chance to notice the post date.   :Ravens - Thank you a lot. The solution, also found in "my assignmnet live update.vi", works perfectly, doing exactly what I needed. Thanks again. kolorek ...

Nested While loop inside For loop
I have been coding in matlab for a while and I am confused about the below code: It seems like the "For loop" iterator variable "Index" does not update inside the "While loop". Please help me understand! I hate to assume this is some error induced on Matlab's end. ---------- CODE ------------ for Index = 390000:length(Stopxy) fprintf('Index: %d, \n',Index); while (Stopxy_YCoord(Index) < LowToHighThresh) fprintf('Index: %d, Yval: %f \n',Index,Stopxy_YCoord(Index)); Stopxy_YCoord(Index); Index = Index + 1; ...

Ending a while loop inside a while loop
How do I make a while loop run as long as the while loop that contains it is running? I tried wiring both conditional terminals to a stop button in the outer loop, but that doesnt seem to work? Is there another way?   Thanks. It doesn't work because of data dependency. Once you are inside the inner loop the outer loop will not go to the next iteration until the inner loop is done. It sounds to me like you want parallel loops running, rather than one inside the other. If you open the Example Finder (Help -> Find Examples), and search for "loops", open the examples...

timed loop inside a while loop
Hi all, I want to ask if I have a timed loop inside a  while loop ,  the timed loop  does a certain task  a 100 iteration ( each time loop iteration is 2 second duration) each while loop iteration  , at each  while loop iteration the time loop writes the actual time spent to a text file for this certain task.   for the next while loop, the timed loop contiues  to write the time spent from the previous while loop ( ex the first while loop the time loop ends the last results with 200 second for a 100  time ...

Loop with 2 loops. Start 2 'inside' loops at different time.
Hello,   I've got a question. Is there a technique or a certain road which will provides the following... I have a while loop. In that while loop I have some other while loops. Now I want to start the while loops in the big loop at differents time... how can I do that...   I included the problem in the vi. When I press start for inside loop 1 I can't start inside loop 2.  It's obvious that I can't do that because I can't iniziate a other while loop because the 'inside' loop is still running. But is there a certain technique for this? It is...

Putting the loop inside of loop properly
I just would like to make my previous question simpler and I bit adjusted m= y code with help with Ulich and Chris. The basic structure of my code is: for c in range(5,25): for columns in ( raw.strip().split() for raw in f ): a.append(columns[c]) x =3D np.array(a, float) not_nan =3D np.logical_not(np.isnan(x)) indices =3D np.arange(len(x)) interp =3D interp1d(indices[not_nan], x[not_nan], kind =3D 'nearest= ') p =3D interp(indices) N =3D len(p) fpsd =3D plot_freq*PSD ...