From: Kenny McCormack on
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...

From: pk on
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.
From: Kenny McCormack on
In article <i246br$vjs$1(a)speranza.aioe.org>, pk <pk(a)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...

From: Kenny McCormack on
In article <i24at9$rc5$1(a)news.xmission.com>,
Kenny McCormack <gazelle(a)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 -

From: pk on
On Tue, 20 Jul 2010 14:12:57 +0000 (UTC) gazelle(a)shell.xmission.com (Kenny
McCormack) wrote:

> In article <i246br$vjs$1(a)speranza.aioe.org>, pk <pk(a)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.