medin@cod.nosc.mil (Ted Medin) (05/24/91)
When using the bourne shell: pwd > temp read dir < temp Just hangs until you type something on the keyboard when using bsd 4.3. However on a sun machine it works fine, the variable dir gets the current working directory. Is "read" keyboard input only or ?????
jerry@ora.com (Jerry Peek) (05/25/91)
In article <3089@cod.NOSC.MIL> medin@cod.nosc.mil (Ted Medin) writes: > pwd > temp > read dir < temp > > Just hangs until you type something on the keyboard when using bsd 4.3. > Is "read" keyboard input only or ????? On some Bourne shells, you can't redirect the input of "read" that way. I used 4.3BSD five years ago or so and I'm pretty sure that was the case. You should probably be using command substitution instead of a "read" command, anyway. This command will do the same thing without a temp file: dir="`pwd`" --Jerry Peek @ O'Reilly & Associates, jerry@ora.com
chawley@sundiver.esd.sgi.com (Christopher J. Hawley) (06/07/91)
In article <3089@cod.NOSC.MIL>, medin@cod.nosc.mil (Ted Medin) writes: |> When using the bourne shell: |> |> pwd > temp |> read dir < temp |> |> Just hangs until you type something on the keyboard when using bsd 4.3. |> However on a sun machine it works fine, the variable dir gets the current |> working directory. |> Is "read" keyboard input only or ????? From The UNIX Programming Environment, Kernighan & Pike, pp. 159-160: -------------------------------- " read can only read from the standard input; it can't even be redirected. None of the shell built-in commands (as opposed to the control flow primitives like for ) can be redirected with > or < : [example omitted] "This might be described as a bug in the shell, but it is a fact of life. Fortunately, it can usually be circumvented by redirecting the loop surrounding the read . This is the key to our implementation of the pick command: " [example of shell command pick omitted] So, in any environment (with the dubious exception of Sun's), you can say for foo in dummy do read dir done < temp with the desired results. Any of the control flow primitives can be used to achieve the same effect... while : ; do read dir; break; done < temp is another way to get what you want. For the curious: what version of Sun software are you running which has the sh behaviour you describe? #include <std_disclaimer.h> /* SGI delivers mail, but I write the opinions contained herein. */ --- Christopher J. Hawley / esper chawley@sundiver.esd.sgi.com Silicon Graphics, Inc. 1L-945 phone: 415 / 335-1621 Mountain View, CA 94039-7311 USA 408 / 243-1042 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Nicht nur wie schnell Sie fahren, sondern _wie_ Sie schnell fahren."
guy@auspex.auspex.com (Guy Harris) (06/09/91)
> From The UNIX Programming Environment, Kernighan & Pike, pp. 159-160: > -------------------------------- > > " read can only read from the standard input; it can't even > be redirected. None of the shell built-in commands (as opposed > to the control flow primitives like for ) can be redirected > with > or < : Old versions of the Bourne shell were less friendly towards redirecting the I/O of built-in commands than later versions; perhaps K&P are describing the old V7 version (the BSD version is pretty much the old V7 version). > "This might be described as a bug in the shell, but it is a > fact of life. Maybe it was a "fact of life" at the time K&P wrote that sentence - or, at least a "fact of life" on the flavor of UNIX they were using at the time they wrote that sentence - but it's most definitely *not* a "fact of life" on System V Release 3.x, or systems with System V Release 3.x-derived Bourne shells, such as SunOS 4.x (nor, I suspect, on systems with System V Release 2.x-derived Bourne shells, such as SunOS 3.x). I don't remember whether it was a "fact of life" on System V Release 2 or not; however, since "echo" has been a Bourne shell builtin in S5 since at least S5R2's Bourne shell, and since "echo"s standard output is often redirected, I suspect it wasn't a "fact of life" there. Perhaps it even works in Version 8's shell.... >So, in any environment "*Any* environment"? That's a pretty sweeping claim, and such claims are dangerous to make. Have you actually used *every* UNIX environment other than SunOS? In particular, SGI's environment includes an S5-based shell; did you try the example on an SGI machine? If so, and if it didn't work, is the version of IRIX you used based on S5R2 or S5R3 or some earlier version of S5? > (with the dubious exception of Sun's), "*Dubious* exception"? What's "dubious" about something as useful as being able to redirect the I/O of shell builtins? Surely not that it goes against the now-out-of-date claim in that version of K&P that it's a "fact of life" that you can't redirect the I/O of shell builtins?