zsh-users
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@brasslantern.com>
To: Sweth Chandramouli <sweth@astaroth.nit.gwu.edu>,
	ZSH Users <zsh-users@math.gatech.edu>
Subject: Re: init files
Date: Sun, 9 Aug 1998 20:51:00 -0700	[thread overview]
Message-ID: <980809205100.ZM24722@candle.brasslantern.com> (raw)
In-Reply-To: <19980809210204.33286@astaroth.nit.gwu.edu>

On Aug 9,  9:02pm, Sweth Chandramouli wrote:
} Subject: Re: Re: init files
}
} 	regardless, here is my revised list of tests for the sourcing of
} the various rc files.  [...]  do these look right, or 
} am i missing anything else?

They're all more complicated than they need to be.  The tests zsh does
are very simple:
	[1] Is RCS unset?
	[2] Is LOGIN set?
	[3] Is INTERACTIVE set?

Everything else you include in your lists simply determines the state of
those three options.

} for one, does it make sense for the precedence of `unsetopt RCS' to be
} different from that of `setopt RCS' in test one?  everywhere else, the
} inversions of options seem to have the same precedence as each other.

I don't quite understand what you mean by "precedence."  Any setopt or
unsetopt that happens in /etc/zshenv can change the command line options,
except for -i/+i.  The command line options can change the defaults or
the values determined by tests like isatty(0).  That's all there is.

If you mean that the lists under each of your test numbers are supposed
to be in some sort of order, then you have the order wrong.

[1]   DEFAULT--rc-enabled shell                 => RCS
        unless
      `-f' flag present on shell invocation     => NO_RCS
        unless
      `+f' flag present on shell invocation     => RCS
        unless
    ( `unsetopt RCS' called in /etc/zshenv      => NO_RCS
        or
      `setopt RCS' called in /etc/zshenv        => RCS )

[2]   DEFAULT--non-login shell                  => NO_LOGIN
        unless
      first character of argv[0] is `-'         => LOGIN
        unless
    ( `+l' flag present on shell invocation     => NO_LOGIN
        or
      `-l' flag present on shell invocation     => LOGIN )
        unless
    ( `unsetopt LOGIN' called before test       => NO_LOGIN
        or
      `setopt LOGIN' called before test         => LOGIN )

[3]   DEFAULT--non-interactive shell            => NO_INTERACTIVE
        unless
      stdin is a tty (isatty(0) is true)        => INTERACTIVE
        unless
      script name present on shell invocation   => NO_INTERACTIVE
        unless
      `-s' flag present on shell invocation     => INTERACTIVE
           *and* stdin is a tty
	unless
      `-c' flag present on shell invocation     => NO_INTERACTIVE
        unless
    ( `-i' flag present on shell invocation     => INTERACTIVE
        or
      `+i' flag present on shell invocation     => NO_INTERACTIVE )

Note that there are two "oddities" here:  First, +f always wins over -f
when both appear, no matter in what order; for all the other flags,
whichever one comes last wins.  I don't know why this is.  Second, +s
cannot unset SHINSTDIN when there is no other possible source of input,
which is why I listed "script name present" instead of +s.

} secondly, is there any way to ensure that an action will be taken for all
} users upon logout?

Not really; you summed up the situation accurately.

} finally, what is the purpose of the `+i' flag?
} `zsh +i' doesn't spawn a non-interactive shell (which would, i would
} imagine, immediately exit without some source of input), but instead
} spawns a shell where the only option set is SHIN_STDIN, but which is
} still interactive (and which ignores PROMPT, it seems).

You're confusing "interactive" with "reads from the tty."  A shell that
doesn't prompt is not "interactive."  It's reading commands from stdin,
and stdin happens to be a tty, but the shell doesn't care.  You'll note
that it doesn't do other interactive things either, e.g., it ignores the
CORRECT option, it won't let you setopt ZLE, and if you type ctrl-Z you
suspend the whole shell.

As for what the purpose is, well, I can come up with only rather far-
fetched examples of cases when you might use it, but it's there just in
case.

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


  reply	other threads:[~1998-08-10  4:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-08-09 19:08 Sweth Chandramouli
1998-08-09 22:04 ` Bart Schaefer
1998-08-10  1:02   ` Sweth Chandramouli
1998-08-10  3:51     ` Bart Schaefer [this message]
1998-08-15 17:24       ` Bart Schaefer
1998-08-10  9:13     ` Zefram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=980809205100.ZM24722@candle.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=sweth@astaroth.nit.gwu.edu \
    --cc=zsh-users@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).