* Fwd: exec - interactive vs non-interactive shell @ 2011-06-01 19:55 Radoulov, Dimitre 2011-06-01 20:42 ` Peter Stephenson 0 siblings, 1 reply; 5+ messages in thread From: Radoulov, Dimitre @ 2011-06-01 19:55 UTC (permalink / raw) To: zsh-users Hi all, could anybody explain what happens here? zsh-4.3.11[t]% cat a_script exec cat ok zsh-4.3.11[t]% zsh-4.3.11[t]% zsh< a_script ok zsh-4.3.11[t]% zsh -i< a_script zsh-4.3.11[t]% No output with -i. bash does the opposite: zsh-4.3.11[t]% bash< a_script zsh-4.3.11[t]% bash -i< a_script 4.2.8(1)-release$ exec cat ok zsh-4.3.11[t]% Best regards Dimitre ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: exec - interactive vs non-interactive shell 2011-06-01 19:55 Fwd: exec - interactive vs non-interactive shell Radoulov, Dimitre @ 2011-06-01 20:42 ` Peter Stephenson 2011-06-01 22:03 ` Radoulov, Dimitre 0 siblings, 1 reply; 5+ messages in thread From: Peter Stephenson @ 2011-06-01 20:42 UTC (permalink / raw) To: zsh-users On Wed, 01 Jun 2011 21:55:04 +0200 "Radoulov, Dimitre" <cichomitiko@gmail.com> wrote: > zsh-4.3.11[t]% cat a_script > exec cat > ok > zsh-4.3.11[t]% > > > zsh-4.3.11[t]% zsh< a_script > ok So cat has taken over stdin, as expected. > zsh-4.3.11[t]% zsh -i< a_script > zsh-4.3.11[t]% > > > No output with -i. You're confusing the effects of "zsh -i <a_script" with "zsh -i a_script". The first one starts up zsh as an interactive shell, with a line editor, but with standard input (not commands, which are interactive) coming from a_script. You'll find that prompt on the line after is inside the new interactive shell. Try typing at this point: read print $REPLY You should see "exec ok". The rules for how zsh finds the commands and standard input are roughly: - Standard input is only redirected if you explicitly use a "<". (So "zsh a_script" leaves stdin where it is and cat hangs waiting for input.) It's independent of interaction with the terminal for reading commands (though there's the more complicated issue of how the terminal gets set up in the first place). - If there's a script name, use that for commands, regardless of whether the shell is interactive or not. (So "zsh -i a_script" behaves basically like without the -i, although you could have interactive shell commands such as vared in the script.) - If there's no script name and the shell is interactive, use the terminal for commands. - If there's no script name and the shell is not interactive, fall back to reading commands from standard input. This is the only case (without making special arrangements) where commands and standard input come from the same channel. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: exec - interactive vs non-interactive shell 2011-06-01 20:42 ` Peter Stephenson @ 2011-06-01 22:03 ` Radoulov, Dimitre 2011-06-02 8:59 ` Peter Stephenson 0 siblings, 1 reply; 5+ messages in thread From: Radoulov, Dimitre @ 2011-06-01 22:03 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-users On 01/06/2011 22:42, Peter Stephenson wrote: > On Wed, 01 Jun 2011 21:55:04 +0200 > "Radoulov, Dimitre"<cichomitiko@gmail.com> wrote: >> zsh-4.3.11[t]% cat a_script >> exec cat >> ok >> zsh-4.3.11[t]% >> >> >> zsh-4.3.11[t]% zsh< a_script >> ok > So cat has taken over stdin, as expected. > Yes, ash, dash and bash, for example, behave differently (ksh and variants seem to behave like zsh). Do you know if this behavior is defined by the POSIX standard? >> zsh-4.3.11[t]% zsh -i< a_script >> zsh-4.3.11[t]% >> >> >> No output with -i. > You're confusing the effects of "zsh -i<a_script" with "zsh -i > a_script". The first one starts up zsh as an interactive shell, with a > line editor, but with standard input (not commands, which are > interactive) coming from a_script. You'll find that prompt on the line > after is inside the new interactive shell. Try typing at this point: > > read > print $REPLY > > You should see "exec ok". > > The rules for how zsh finds the commands and standard input are roughly: > > - Standard input is only redirected if you explicitly use a "<". > (So "zsh a_script" leaves stdin where it is and cat hangs waiting for > input.) It's independent of interaction with the terminal for reading > commands (though there's the more complicated issue of how the terminal > gets set up in the first place). > > - If there's a script name, use that for commands, regardless of whether > the shell is interactive or not. (So "zsh -i a_script" behaves > basically like without the -i, although you could have interactive shell > commands such as vared in the script.) > > - If there's no script name and the shell is interactive, use the > terminal for commands. > > - If there's no script name and the shell is not interactive, fall back > to reading commands from standard input. This is the only case (without > making special arrangements) where commands and standard input come from > the same channel. > If the shell is interactive, there's no script name nor explicit input redirection (<) , command and standard input come from the same channel too (the terminal), or I'm missing something? Thank you for the explanation! Regards Dimitre ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: exec - interactive vs non-interactive shell 2011-06-01 22:03 ` Radoulov, Dimitre @ 2011-06-02 8:59 ` Peter Stephenson 2011-06-02 9:37 ` Radoulov, Dimitre 0 siblings, 1 reply; 5+ messages in thread From: Peter Stephenson @ 2011-06-02 8:59 UTC (permalink / raw) To: zsh-users On Wed, 01 Jun 2011 23:03:23 +0100, Radoulov, Dimitre <cichomitiko@gmail.com> wrote: > On 01/06/2011 22:42, Peter Stephenson wrote: >> On Wed, 01 Jun 2011 21:55:04 +0200 >> "Radoulov, Dimitre"<cichomitiko@gmail.com> wrote: >>> zsh-4.3.11[t]% cat a_script >>> exec cat >>> ok >>> zsh-4.3.11[t]% >>> >>> >>> zsh-4.3.11[t]% zsh< a_script >>> ok >> So cat has taken over stdin, as expected. >> > ash, dash and bash, for example, behave differently (ksh and variants > seem to behave like zsh). > Do you know if this behavior is defined by the POSIX standard? I suppose this is down to the behaviour of exec. I didn't see anything in the standard about what it should do with stdin when the current shell was replaced with no additional redirection. I think what's happened is probably that the shells that don't show you anything have read ahead, so you still keep stdin from the same place, but you don't necessarily get the very next line. I suspect this behaviour isn't defined. (If that's right, then zsh's and ksh's behaviour is the philosophically correct one, but there are extenuating circumstances for the others.) > If the shell is interactive, there's no script name nor explicit input > redirection (<) , > command and standard input come from the same channel too (the terminal), > or I'm missing something? You're not fundamentally missing anything, no, I deliberately glossed over the way the shell opens the terminal. It is based on stdin, but in practice the shell duplicates the file descriptor and does its terminal processing on a hidden one (i.e. greater than 9). pws Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: exec - interactive vs non-interactive shell 2011-06-02 8:59 ` Peter Stephenson @ 2011-06-02 9:37 ` Radoulov, Dimitre 0 siblings, 0 replies; 5+ messages in thread From: Radoulov, Dimitre @ 2011-06-02 9:37 UTC (permalink / raw) To: zsh-users On 02/06/2011 10:59, Peter Stephenson wrote: > On Wed, 01 Jun 2011 23:03:23 +0100, Radoulov, Dimitre > <cichomitiko@gmail.com> wrote: >> On 01/06/2011 22:42, Peter Stephenson wrote: >>> On Wed, 01 Jun 2011 21:55:04 +0200 >>> "Radoulov, Dimitre"<cichomitiko@gmail.com> wrote: >>>> zsh-4.3.11[t]% cat a_script >>>> exec cat >>>> ok >>>> zsh-4.3.11[t]% >>>> >>>> >>>> zsh-4.3.11[t]% zsh< a_script >>>> ok >>> So cat has taken over stdin, as expected. >>> >> ash, dash and bash, for example, behave differently (ksh and variants >> seem to behave like zsh). >> Do you know if this behavior is defined by the POSIX standard? > > I suppose this is down to the behaviour of exec. I didn't see anything > in the standard about what it should do with stdin when the current > shell was replaced with no additional redirection. > > I think what's happened is probably that the shells that don't show > you anything have read ahead, so you still keep stdin from the same > place, but you don't necessarily get the very next line. I suspect > this behaviour isn't defined. (If that's right, then zsh's and ksh's > behaviour is the philosophically correct one, but there are > extenuating circumstances for the others.) > >> If the shell is interactive, there's no script name nor explicit >> input redirection (<) , >> command and standard input come from the same channel too (the >> terminal), >> or I'm missing something? > > You're not fundamentally missing anything, no, I deliberately glossed > over the way the shell opens the terminal. It is based on stdin, > but in practice the shell duplicates the file descriptor and does > its terminal processing on a hidden one (i.e. greater than 9). > Thanks again! Best regards Dimitre ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-06-02 9:37 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-06-01 19:55 Fwd: exec - interactive vs non-interactive shell Radoulov, Dimitre 2011-06-01 20:42 ` Peter Stephenson 2011-06-01 22:03 ` Radoulov, Dimitre 2011-06-02 8:59 ` Peter Stephenson 2011-06-02 9:37 ` Radoulov, Dimitre
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).