[vim/vim] Terminal inside Vim sets $LINES environment variable globally instead of locally? (Issue #12160)

user202729

unread,

Mar 16, 2023, 1:50:18 AM3/16/23

to vim/vim, Subscribed

I'm not sure if this is a bug or not.

Basically, if we use bash, then the subprocesses does not inherit the values of $LINES environment variable...

$ echo $LINES
100
$ bash -c 'echo $LINES'

$ bash -ic 'echo $LINES'
100
$

here, in the second invocation, $LINES environment variable is not inherited from the parent bash process.

However, in vim, $LINES are set globally -- if you execute the same commands in a :term inside vim,
the second line will also print out the number.

(note: I think https://stackoverflow.com/q/1780483/ says that these variables should be set "locally" only, but
it doesn't explain why.)

This is a problem because when I run :term in vim, then run ipython (now in vim/term os.environ["LINES"]
is a fixed value, while in xterm/bash it's not set), then run less from it, the LINES is fixed regardless of changes
to the environment variable. Unsetting LINES in ipython works as a workaround.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

user202729

unread,

Mar 16, 2023, 1:56:19 AM3/16/23

to vim/vim, Subscribed

I think the code responsible for that is https://github.com/vim/vim/blob/67578e5bcf7404d40d42876b738b72e68add1a3e/src/os_unix.c#L4285

Maybe it's better to not set the environment variables instead, and let the subprocess e.g. bash detect it itself? Does it break anything?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Gary Johnson

unread,

Mar 16, 2023, 2:52:03 PM3/16/23

to reply+ACY5DGBS5WDIZZAEXC...@reply.github.com, vim...@googlegroups.com

On 2023-03-15, user202729 wrote:
> I'm not sure if this is a bug or not.
>
> Basically, if we use bash, then the subprocesses does not inherit the values of
> $LINES environment variable...
>
> $ echo $LINES
> 100
> $ bash -c 'echo $LINES'
>
> $ bash -ic 'echo $LINES'
> 100
> $
>
> here, in the second invocation, $LINES environment variable is not inherited
> from the parent bash process.
>
> However, in vim, $LINES are set globally -- if you execute the same commands in
> a :term inside vim,
> the second line will also print out the number.
>
> (note: I think https://stackoverflow.com/q/1780483/ says that these variables
> should be set "locally" only, but
> it doesn't explain why.)

I didn't get from that article that LINES _should_ not be exported,
just that it wasn't.

This never made sense to me. Several programs use LINES and COLUMNS
to know how large a display they have to work with, so I would think
that they would always be exported. Many years ago, I put the
following in my ~/.bashrc and haven't had any related problems
since.

export LINES
export COLUMNS
shopt -s checkwinsize

> This is a problem because when I run :term in vim, then run ipython (now in vim
> /term os.environ["LINES"]
> is a fixed value, while in xterm/bash it's not set), then run less from it, the
> LINES is fixed regardless of changes
> to the environment variable. Unsetting LINES in ipython works as a workaround.

Your problem seems to be not that LINES is exported but that it
sometimes has the wrong value. I don't understand what you mean
when you say it is "fixed regardless of changes". It sounds like
you are setting LINES in one process and expecting to affect
another, already-running process. You might have a look at this
article:

https://help.ubuntu.com/community/EnvironmentVariables

It would help us to solve this issue if you provided more details,
such as exactly what you do to observe the problem and what the
problem is.

user202729 later wrote:
> I think the code responsible for that is https://github.com/vim/vim/blob/
> 67578e5bcf7404d40d42876b738b72e68add1a3e/src/os_unix.c#L4285
>
> Maybe it's better to not set the environment variables instead, and let the
> subprocess e.g. bash detect it itself? Does it break anything?

I am not aware of a specification that says what a program _should_
or _must_ do with environment variables when it forks a child, but
I like that vim does what it does; it avoids problems from programs
that expect to have LINES and COLUMNS set when they are run.
Changing it would probably break some users' scripts. Moreover,
I don't see how it should break anything the way it is now.

Regards,
Gary

vim-dev ML

unread,

Mar 16, 2023, 2:52:22 PM3/16/23

to vim/vim, vim-dev ML, Your activity

On 2023-03-15, user202729 wrote:
> I'm not sure if this is a bug or not.
>
> Basically, if we use bash, then the subprocesses does not inherit the values of
> $LINES environment variable...
>
> $ echo $LINES
> 100
> $ bash -c 'echo $LINES'
>
> $ bash -ic 'echo $LINES'
> 100
> $
>
> here, in the second invocation, $LINES environment variable is not inherited
> from the parent bash process.
>
> However, in vim, $LINES are set globally -- if you execute the same commands in
> a :term inside vim,
> the second line will also print out the number.
>
> (note: I think https://stackoverflow.com/q/1780483/ says that these variables
> should be set "locally" only, but
> it doesn't explain why.)

I didn't get from that article that LINES _should_ not be exported,
just that it wasn't.

This never made sense to me. Several programs use LINES and COLUMNS
to know how large a display they have to work with, so I would think
that they would always be exported. Many years ago, I put the
following in my ~/.bashrc and haven't had any related problems
since.

export LINES
export COLUMNS
shopt -s checkwinsize

> This is a problem because when I run :term in vim, then run ipython (now in vim
> /term os.environ["LINES"]
> is a fixed value, while in xterm/bash it's not set), then run less from it, the
> LINES is fixed regardless of changes
> to the environment variable. Unsetting LINES in ipython works as a workaround.

Your problem seems to be not that LINES is exported but that it
sometimes has the wrong value. I don't understand what you mean
when you say it is "fixed regardless of changes". It sounds like
you are setting LINES in one process and expecting to affect
another, already-running process. You might have a look at this
article:

https://help.ubuntu.com/community/EnvironmentVariables

It would help us to solve this issue if you provided more details,
such as exactly what you do to observe the problem and what the
problem is.

user202729 later wrote:
> I think the code responsible for that is https://github.com/vim/vim/blob/
> 67578e5bcf7404d40d42876b738b72e68add1a3e/src/os_unix.c#L4285
>
> Maybe it's better to not set the environment variables instead, and let the
> subprocess e.g. bash detect it itself? Does it break anything?

I am not aware of a specification that says what a program _should_
or _must_ do with environment variables when it forks a child, but
I like that vim does what it does; it avoids problems from programs
that expect to have LINES and COLUMNS set when they are run.
Changing it would probably break some users' scripts. Moreover,
I don't see how it should break anything the way it is now.

Regards,
Gary

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

user202729

unread,

Mar 17, 2023, 12:17:52 AM3/17/23

to vim/vim, vim-dev ML, Comment

I put a concrete use case which gets broken by vim's setting of environment variable.

This is a problem because when I run :term in vim, then run ipython (now in vim/term os.environ["LINES"]
is a fixed value, while in xterm/bash it's not set), then run less from it, the LINES is fixed regardless of changes
to the environment variable. Unsetting LINES in ipython works as a workaround.

To clarify, I do this:

In vim :term.
In the newly opened terminal, run ipython.
Inside ipython, run import sys.
run sys?. The less window is displayed correctly.
resize vim.
Run sys? again. The less window is garbled.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Mar 17, 2023, 5:11:22 AM3/17/23

to vim/vim, vim-dev ML, Comment

Oh, I always thought it's the terminals responsibility to set the $LINES and $COLUMNS at least initially.

Now it may be fine for bash to automatically set the $LINES and $COLUMNS for the scripts it runs,
but keep in mind, you can also run the terminal like this :term script where no shell is involved and that called process
may still expect $LINES to be available (and not able to automatically determine $LINES) (e.g. running :term vim)

So I don't think removing LINES from the environment is a solution.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

user202729

unread,

Mar 17, 2023, 9:08:09 AM3/17/23

to vim/vim, vim-dev ML, Comment

but... if you run a script from bash the normal way, namely ./a.sh or bash a.sh then $LINES won't be set for the script anyway?

Unless you're running it like bash -i a.sh or source a.sh from bash, but then in that case the equivalent would be to do :term bash -i a.sh in vim.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Mar 17, 2023, 9:25:44 AM3/17/23

to vim/vim, vim-dev ML, Comment

That comes back to what Gary said above. Several programs seem to require it, so it makes sense to export it.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Bram Moolenaar

unread,

Mar 18, 2023, 9:38:19 AM3/18/23

to vim/vim, vim-dev ML, Comment

> I put a concrete use case which gets broken by vim's setting of
> environment variable.
>

> > This is a problem because when I run `:term` in vim, then run
> > `ipython` (now in vim/term `os.environ["LINES"]` is a fixed value,
> > while in xterm/bash it's not set), then run `less` from it, the
> > LINES is fixed regardless of changes to the environment variable.
> > Unsetting `LINES` in ipython works as a workaround.
>

> To clarify, I do this:
>

> * In vim `:term`.
> * In the newly opened terminal, run `ipython`.
> * Inside `ipython`, run `import sys`.
> * run `sys?`. The `less` window is displayed correctly.
> * resize `vim`.
> * Run `sys?` again. The `less` window is garbled.

This is normal. The environment variable $LINES (or the exported shell
variable) is passed to the child process when it's created. Changing
the value when the terminal is resized is the job of the child process.
This normally uses the SIGWINCH signal.

Not setting $LINES is a bad idea, many programs depend on it.

--
Facepalm statement #7: "Last week I almost got pregnant!"

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

vim-dev ML

unread,

Mar 18, 2023, 9:38:21 AM3/18/23

to vim/vim, vim-dev ML, Your activity

> > (note: I think https://stackoverflow.com/q/1780483/ says that these variables
> > should be set "locally" only, but
> > it doesn't explain why.)
>

> I didn't get from that article that LINES _should_ not be exported,
> just that it wasn't.
>
> This never made sense to me. Several programs use LINES and COLUMNS
> to know how large a display they have to work with, so I would think
> that they would always be exported. Many years ago, I put the
> following in my ~/.bashrc and haven't had any related problems
> since.
>
> export LINES
> export COLUMNS
> shopt -s checkwinsize

In processes there is a separate space for environment variables.
Unfortunately, shells have messed this up by throwing environment
variables and shell variables into the same namespace. Then using the
"export" mechanism to change what variables mean. And there is no
simple way to check if a variable is exported or not. You can use:

declare -p LINES

Which then has the mysterious output:

declare -x LINES="100"

Apparently the "-x" indicates the variable is exported. The bash manual
page doesn't mention whether LINES is exported or not...

The "-i" argument to bash is poorly documented. It says it means
"interactive", but then what "interactive" means is spread out in the
manual page. I guess that omitting "-i", thus a non-interactive shell,
doesn't use SIGWINCH. Searching for "SIGWINCH" indeed finds this in the
manual page (it's very hard to find unless you know what to search for).

--
Facepalm statement #8: "Drive faster, the petrol is running out"

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Mar 19, 2023, 10:57:06 AM3/19/23

to vim/vim, vim-dev ML, Comment

I don't think this is a bug and therefore this is not going to change. let me close this therefore.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Mar 19, 2023, 10:57:07 AM3/19/23

to vim/vim, vim-dev ML, Comment

Closed #12160 as not planned.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Bram Moolenaar

unread,

Mar 22, 2023, 12:42:00 PM3/22/23

to vim...@googlegroups.com, Gary Johnson, reply+ACY5DGBS5WDIZZAEXC...@reply.github.com

[resend - message got rejected somewhere]

FATHER: Make sure the Prince doesn't leave this room until I come and
get him.
FIRST GUARD: Not ... to leave the room ... even if you come and get him.
FATHER: No. Until I come and get him.
SECOND GUARD: Hic.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\

Reply all

Reply to author

Forward