Re: [PATCH3] Re: avoid closed stdin() in zle widgets

[Bart Schaefer <schaefer@brasslantern.com>]

On Jun 12,  8:02pm, Stephane Chazelas wrote:
}
} My point is that a command should be able to reasonably make some
} assumptions, like:
} 
} - stdin should be open for at least reading
} - stdout, stderr should be open for at least writing

Although I understand the security implication of accidentally opening
some other file onto fd 0/1/2, I can't agree with the above statements.
Taken to the logical conclusion, the >&- <&- or 2>&- operators would
be required always to fail with an error.

It should not be the shell's job to plug this hole.  I will agree that
a valid argument is that the shell should not implicitly *open* this
hole, which one could also argue is what the completion system had
been doing in spite of the behavior being documented.  However, with
these two likely exceptions --

} - argv[0] should be set (argc > 0)
} - no dups in the environment

-- there is nothing else on your list where I would agree that the
shell should ignore the user's directives in the name of protecting
an external command from itself.

} $ (limit stacksize 100k; zsh)
} zsh: segmentation fault
} zsh: segmentation fault
} 
} (twice!?). Is that a bug?

I believe what's happening is that both the zsh inside the subshell
and the parent handling the subshell exit are reporting the error,
so one failure / two messages.

However, I can't test directly because I can start zsh -f with a hard
limit stack size of *zero*, so I'm quite curious as to why you get a
crash on 100k.