When should interactive option be set/.zshrc read?

When should interactive option be set/.zshrc read?

[Andrej Borsenkow]

I was sure, that my .zshrc was read only by interactice zsh, but

bor@itsrm2% print $options[interactive]
on <= correct
bor@itsrm2% : | (print $options[interactive])
on <= ?? I doubt, this shell can be considered "interactive"

The reason I noted this, I used something like

tar cf - . | (cd /foo && tar xf -)

and my .zshrc defines chpwd() function that changes window title. It was
suddenly changed. But then it means, that all initialization, including
completion, takes place. I believe, it is wrong. I /think/ it was changed
fairly recently, but I may be wrong.

-andrej

Have a nice DOS!
B >>

Re: When should interactive option be set/.zshrc read?

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> I was sure, that my .zshrc was read only by interactice zsh, but
> 
> bor@itsrm2% print $options[interactive]
> on <= correct
> bor@itsrm2% : | (print $options[interactive])
> on <= ?? I doubt, this shell can be considered "interactive"

It's a copy of the interactive shell, a subshell. It doesn't read any
init files whatsoever.

Hm, but maybe we should turn off the option in subshells. (And probably 
other options, too?)


Non-interactive shells do things like running shell scripts (`#!.../zsh').


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: When should interactive option be set/.zshrc read?

[Peter Stephenson]

> I was sure, that my .zshrc was read only by interactice zsh, but
> 
> bor@itsrm2% print $options[interactive]
> on <= correct
> bor@itsrm2% : | (print $options[interactive])
> on <= ?? I doubt, this shell can be considered "interactive"

This is a completely different matter.  The subshell inherits everything
from the parent shell after the fork; it never re-initialiases.  It does
unset the options MONITOR and USEZLE, but not INTERACTIVE, for the
subshell, however.   One might have thought that it would either change all
three or none.  In particular, the effect of claiming to be interactive but
not using ZLE looks a bit weird.  Unless there is some standard behind
this?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

RE: When should interactive option be set/.zshrc read?

[Andrej Borsenkow]

> Andrej Borsenkow wrote:
>
> > I was sure, that my .zshrc was read only by interactice zsh, but
> >
> > bor@itsrm2% print $options[interactive]
> > on <= correct
> > bor@itsrm2% : | (print $options[interactive])
> > on <= ?? I doubt, this shell can be considered "interactive"
>
> It's a copy of the interactive shell, a subshell. It doesn't read any
> init files whatsoever.
>

Um, really. Which is even worse.

> Hm, but maybe we should turn off the option in subshells. (And probably
> other options, too?)
>
> Non-interactive shells do things like running shell scripts (`#!.../zsh').
>

By definition, INTERACTIVE is set "if the standard input is a tty and commands
are being read from standard input". In the above case standard input is not
tty and commands are not being read from standard input.

Well, I am concerned now how to prevent all definitions from .zshrc to be used
in subshell. I definitely do not want that (ls foo| ...) use my alias for ls;
and I do not want window title be mangled. Any idea? Is it possible to provide
"clean sandbox" for subshells?

-andrej

Re: When should interactive option be set/.zshrc read?

[Thomas Köhler]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On Wed, Sep 06, 2000 at 05:05:27PM +0400,
Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru> wrote:
> 
[...]
> > Hm, but maybe we should turn off the option in subshells. (And probably
> > other options, too?)
> >
> > Non-interactive shells do things like running shell scripts (`#!.../zsh').
> >
> 
> By definition, INTERACTIVE is set "if the standard input is a tty and commands
> are being read from standard input". In the above case standard input is not
> tty and commands are not being read from standard input.
> 
> Well, I am concerned now how to prevent all definitions from .zshrc to be used
> in subshell. I definitely do not want that (ls foo| ...) use my alias for ls;
> and I do not want window title be mangled. Any idea? Is it possible to provide
> "clean sandbox" for subshells?

zsh -f

> -andrej

Ciao,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

RE: When should interactive option be set/.zshrc read?

[Andrej Borsenkow]

>
> This is a completely different matter.  The subshell inherits everything
> from the parent shell after the fork; it never re-initialiases.  It does
> unset the options MONITOR and USEZLE, but not INTERACTIVE, for the
> subshell, however.   One might have thought that it would either change all
> three or none.  In particular, the effect of claiming to be interactive but
> not using ZLE looks a bit weird.  Unless there is some standard behind
> this?
>

Here is what SUS V2 says:

A subshell environment will be created as a duplicate of the shell
environment, except that signal traps set by that shell environment will be
set to the default values. Changes made to the subshell environment will not
affect the shell environment. Command substitution, commands that are grouped
with parentheses and asynchronous lists will be executed in a subshell
environment. Additionally, each command of a multi-command pipeline is in a
subshell environment; as an extension, however, any or all commands in a
pipeline may be executed in the current environment. All other commands will
be executed in the current shell environment.

"Environment" includes current option settings, aliases, functions etc. SUS V2
shell supports job control, and has MONITOR option that is on if shell is
interactive. But it is silent on what happens with these options in subshell.

-andrej

Re: When should interactive option be set/.zshrc read?

[Peter Stephenson]

Andrej wrote:
> "Environment" includes current option settings, aliases, functions
> etc. SUS V2 shell supports job control, and has MONITOR option that is on
> if shell is interactive. But it is silent on what happens with these
> options in subshell.

This probably means we've already broken it by unsetting MONITOR, in which
case unsetting INTERACTIVE as well would be logical.

However, it's not true that running in a subshell changes the basic feature
of an interactive shell: standard input remains the tty, and the shell
continues to read commands from the usual source --- unless, of course, the
subshell is for some special purpose, such as a command substitution or
part of a pipeline.  But by that score we would have to unset INTERACTIVE
when the current shell is running as the righthand side of a pipeline,
which is clearly not on.  So it's not all that clear cut.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: When should interactive option be set/.zshrc read?

[Bart Schaefer]

On Sep 6,  2:49pm, Sven Wischnowsky wrote:
} 
} > bor@itsrm2% print $options[interactive]
} > on <= correct
} > bor@itsrm2% : | (print $options[interactive])
} > on <= ?? I doubt, this shell can be considered "interactive"
} 
} It's a copy of the interactive shell, a subshell. It doesn't read any
} init files whatsoever.
} 
} Hm, but maybe we should turn off the option in subshells. (And probably 
} other options, too?)

On Sep 6,  1:51pm, Peter Stephenson wrote:
}
} It does unset the options MONITOR and USEZLE, but not INTERACTIVE, for the
} subshell, however.   One might have thought that it would either change all
} three or none.  In particular, the effect of claiming to be interactive but
} not using ZLE looks a bit weird.

The MONITOR option is turned off because it's used internally to decide
whether you can background a job and then foreground it again.  Although
it might be sensible to do

	(job1 & job2 ; fg)

it's not sensible to do

	(job1 &) ; fg

because the background job is not a child of the shell doing the `fg'.

Possibly the test for whether bg/fg work should be separate from the
test for whether the shell reports a background job's exit status, but
it has never been that way.  Bash, for example, shows the "monitor"
option set if you do `(set -o)', but doesn't track the status of any
background jobs.

Of course, you can get the equivalent of the first example with

	(job1 & job2 ; wait)

USEZLE is a tad odd.  It means you can't do things like

	(vared foo)

I believe the reason for this is that a subshell is also used to run
background jobs and jobs in pipelines, neither of which should mess with
the terminal settings; it's likely that zsh could differentiate a
foreground ( ) from a pipeline or backgrounded command for this purpose,
but presently it does not.

On Sep 6,  5:05pm, Andrej Borsenkow wrote:
} Subject: RE: When should interactive option be set/.zshrc read?
}
} > It's a copy of the interactive shell, a subshell. It doesn't read any
} > init files whatsoever.
} 
} Um, really. Which is even worse.

What?  You've got to be kidding.

} By definition, INTERACTIVE is set "if the standard input is a tty and
} commands are being read from standard input".

That tells how the *startup time* setting of INTERACTIVE is done.  It is
not intended to mean that the option changes every time you redirect input.

} Well, I am concerned now how to prevent all definitions from .zshrc to
} be used in subshell.

If you think about this for even a few minutes, you'll realize that all
sorts of things would break if subshells behaved like "zsh -f".

zagzig[339] bash
[schaefer@zagzig]$ alias ls='echo foo'
[schaefer@zagzig]$ (ls)
foo
[schaefer@zagzig]$ function echo () { /bin/echo bar "$@" }
[schaefer@zagzig]$ (ls)
bar foo
[schaefer@zagzig]$ tcsh
[schaefer@candle]$ alias ls 'echo foo'
[schaefer@candle]$ (ls)
foo
[schaefer@candle]$ exit
[schaefer@candle]$ (sleep 30 & sleep 3; fg)
[1] 22485
No job control in subshells.
[schaefer@zagzig]$ (sleep 30 & sleep 3; fg)
fg: no job control
[schaefer@zagzig]$ exit

(Ignore the silly way that tcsh gets the hostname; "zagzig" and "candle"
are host-aliases for the same machine.)

On Sep 6,  3:12pm, Thomas Köhler wrote:
}
} Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru> wrote:
} > 
} [...]
} > I definitely do not want that (ls foo| ...) use my alias for ls; and
} > I do not want window title be mangled. Any idea? Is it possible to
} > provide "clean sandbox" for subshells?
} 
} zsh -f

More completely,

	zsh -fc 'ls foo|...'

On Sep 6,  5:23pm, Andrej Borsenkow wrote:
}
} Here is what SUS V2 says:
} 
} A subshell environment will be created as a duplicate of the shell
} environment, except that signal traps set by that shell environment
} will be set to the default values.

Yup.

Incidentally, as to your specific problem with chpwd(), why not set the
window title in precmd() instead?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net