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

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/20230316185138.GB13894%40phoenix.

Raspunde prin e-mail lui