On Tue, 11 Jun 2013 13:17:13 +0200 "estew" <est...@gmail.com> wrote:
> On Tuesday, 11 June 2013 at 10:55:16 UTC, Nick Sabalausky wrote: > > On Tue, 11 Jun 2013 09:09:43 +0200 > > Jacob Carlborg <d...@me.com> wrote: > > > >> On 2013-06-11 08:38, Nick Sabalausky wrote: > >> > >> > I just tried both on Debian 6: > >> > > >> > nick@debian6:~$ cat 1< /dev/null > >> > cfws > >> > cat: write error: Bad file descriptor > >> > nick@debian6:~$ echo meh 1< /dev/null > >> > bash: echo: write error: Bad file descriptor > >> > > >> > Maybe OSX behaves differently? > >> > >> I get the same on Mac OS X 10.6.3 using bash. Is Andrei > >> perhaps using another shell? > >> > > > > I think I remember him saying somewhere that he uses zsh, > > although I > > can't look it up or test it on zsh at the moment. > > Just tried zsh, bash, sh.. > > $ echo meh 1< /dev/null > zsh: no output > bash: Bad file descriptor > sh: Bad file descriptor > > $ echo meh 2< /dev/null > zsh: meh > bash: meh > sh: meh > Hmm, yea, sounds like it may not have been the best test in the first place after all if even the shells and stdout-vs-stderr don't all agree with each other. I'm no unix expert, but wouldn't 1</dev/null just mean "If the program tries to read input from stdout, feed it input from /dev/null instead"? Or is that really a known way to force stdout to be read-only?