This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.

stalebot seems keen to close this issue ...

It says on https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea

A comment is all it takes to keep the conversation alive.

Yet, now it's closed ...

Also looking for this feature.

Yes, but stale bot closed the issue two weeks ago, so the maintainers might not see this issue any longer.

pirog removed the wontfix label on Dec 3, 2019

... gives me the impression that this could potentially be looked on. Creating a new identical issue doesn't seem optimal.

AFAIK this is already possible with either an environment file, service level overrides or setting a user space lando global config that overrides the appEnv key.

If those don't work this is something we could look into at some point but i'm guessing it would fall lower on the priority list.

Thanks for your input @pirog. I went back and experimented some more. I could have sworn that I already tried this, but perhaps I forgot to rebuild ... but this works:

Set per project in .lando.yml, as a service level override:

services:
  appserver:
    overrides:
      environment:
        COLUMNS: "140"

...or set with a user space lando global config in ~/.lando/config.yml:

appEnv:
  COLUMNS: "140"

Looking in the output of lando config helped me debug.

• Ubuntu 18.04
• Lando 3.0.0-aft.2
• Drush 9.7.2

I understand it is a matter of taste, but would it make sense to reduce the default number of columns from 256 to for example 180 in https://github.com/lando/lando/blob/master/plugins/lando-core/index.js? Looking at my own command line with COLUMNS=238 makes the font quite small ...

We should revisit this in 4.x...@pirog indicated that in the future we could set container COLUMNS using the host value of COLUMNS, which might be another good solution to follow the user's lead.

@reynoldsalec
Would using host value for COLUMNS update the value on terminal resize if it is updated on host?

@eldair i think it would depend on the usage. in the future im guessing COLUMNS will be set on "execs" which means they will update the next time you run a lando tooling-command. for non cli usage i think youll need to rebuild the app to reset the envvars.

@pirog yeah, I was interested in CLI/tooling (like artisan command)

Yeah artisan commands is my exact usecase here.
Especially with their new formatting it's now quite hard to read when COLUMNS is set incorrectly.

Setting the COLUMNS manually is problematic with splitting/resizing terminals

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.

/unstale

For lando 3 you could pass the local COLUMNS value to lando ssh by using and modifying the wrapper script at #2188 (comment) to add that variable in addition to the TERM value currently being passed along.

(Be aware that other non-trivial env-var values, or non-trivial commands, may fall foul of lando/cli#212; but the likes of env TERM=${TERM} COLUMNS=${COLUMNS} ... are going to be fine.)

You might need to use tput cols to obtain a value earlier in the script. My comments about "older versions of tput" are themselves somewhat old now, so YMMV on the extra hoops here...

# Check how many columns the terminal has.  Older versions of tput return
# "80" here when both stdout and stderr have been redirected, so running
# 'tput cols 2>/dev/null' in a subshell is a problem.  Instead we check
# whether it exits successfully, so that we can call it again without the
# stderr redirection.
if [ -z "${COLUMNS}" ]; then
    if command -v tput >/dev/null 2>&1 && tput cols >/dev/null 2>&1; then
        COLUMNS="$(tput cols)"
    fi
fi