zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <Peter.Stephenson@csr.com>
To: zsh workers <zsh-workers@zsh.org>
Subject: Re: crashes when setting COLUMNS=0 or 1
Date: Tue, 26 Jun 2012 10:33:14 +0100	[thread overview]
Message-ID: <20120626103314.61c6567b@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <120626003042.ZM19270@torch.brasslantern.com>

On Tue, 26 Jun 2012 00:30:42 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> So, interesting side-effect:  If my patch for IPDEF5 is applied, then
> settings of COLUMNS and LINES get propagated through to the tty driver
> and can end up affecting the behavior of the parent shell (or anything
> else that's using the terminal where those values were changed), even
> after the shell where the assignments were made has exited.
> 
> E.g. (COLUMNS=20) in a subshell will change the tty driver which will
> signal the parent shell which will pick up the change and set its own
> column width to 20.  This is the only case I can think of where a
> parameter assigned in a subshell can behave this way.

That's not necessarily always a problem.  The parent is in case subject
to such changes asynchronously via SIGWINCH.  The fact that it's getting
the value a different way shouldn't make matters worse in general.

Where it's unhelpful is if you're setting COLUMNS not because anything
has changed but as a temporary trick for some utility that tests it and
truncates.  Then you wouldn't want the change to propagate back.

This is going to be niggling if it means these two have different
effects:

COLUMNS=20 ls
(export COLUMNS=20; ls)

since they look as if they ought to be similar.

Howeve, I'm not sure what can reasonably be done.  Restoring COLUMNS on
exit from a subshell doesn't seem a particularly clean thing to do, but
might work in most cases.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


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


  reply	other threads:[~2012-06-26  9:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-09 10:36 Mikael Magnusson
2012-06-26  3:38 ` Geoff Wing
2012-06-26  7:03   ` Bart Schaefer
2012-06-26  7:21     ` Bart Schaefer
2012-06-26  7:30     ` Bart Schaefer
2012-06-26  9:33       ` Peter Stephenson [this message]
2012-06-26 14:26         ` Bart Schaefer

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=20120626103314.61c6567b@pwslap01u.europe.root.pri \
    --to=peter.stephenson@csr.com \
    --cc=zsh-workers@zsh.org \
    /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).