Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

100% width doesn't work on MacOS, always 80 chars wide #51

Open
mrjones-plip opened this issue Aug 24, 2021 · 6 comments
Open

100% width doesn't work on MacOS, always 80 chars wide #51

mrjones-plip opened this issue Aug 24, 2021 · 6 comments

Comments

@mrjones-plip
Copy link
Contributor

Intro

Hi there! I'm really pleased with bashsimplecurses - thank you!! I've just launched a tool that uses it and we're seeing that MacOS users do not get a full width window when running a script that declares window "100% wide window" "red" "100%" Instead an 80 char wide window is shown. Since our script displays information that some times is wider than 80 chars, it'd be great if bashsimplecurses supported full width on MacOS.

Steps to reproduce

  1. Be on MacOS - tested on 10.13.6 and 11.x & in ohmyzsh, bash and sh
  2. Clone this repo (as of 054a04a)
  3. cd into ./bashsimplecurses/examples
  4. Create a file called macos.sh with this contents:
    #!/bin/bash
    . `dirname $0`/../simple_curses.sh
    main (){
        window "100% wide window" "red" "100%"
        append "`date`"
        endwin
    }
    main_loop -t 0.5 "$@"
  5. Run chmod +x macos.sh&& ./macos.sh

Expected: Window is shown full width of current terminal
Actual: Window is always shown at 80 chars wide, no bigger, no smaller

Related - setting it to 50% in the script seems to show it at 40 chars wide ( i guess half of the 80 chars it thinks the terminal always is)

Screenshots

Here's a local shell on Ubuntu 20.04/ohmyzsh on the top and and SSH shell on macos/ohmyzsh on the bottom. The first shows a screen ~107 chars wide, the second shows one ~40 chars wide:

too narrow
too wide

Here's the same script running on in a local shell on MacOS:

native mac os

@mrjones-plip
Copy link
Contributor Author

Doing a little poking around, the problem seems to stem from the tput cols call in the window() function. When I call it on the bare command line on MacOS I get the accurate answer. When it's called in the subshell in window(), it ALWAYS returns 80.

I wonder if it has to do with an old version of ncurses? On my Ubuntu 18 box i get ncurses 6.1.20180127 but on the two MacOS boxes I just tested on (one High Sierra 10.13.6 and one Big Sur 11.4) they both have the exact same version: ncurses 5.7.20081102

@mrjones-plip
Copy link
Contributor Author

mrjones-plip commented Aug 25, 2021

ah - confirmed! I used Homebrew and to upgrade ncurses on my MacOS box:

/usr/local/Cellar/ncurses/6.2/bin/tput -V
ncurses 6.2.20200212

I then forced Bash simple curses to use this version and the problem went away. I'll do a little more testing to see if there's a way to be backwards compatible with out any regressions.

@mrjones-plip
Copy link
Contributor Author

So, my work around is to:

  1. install Homebew
  2. install ncurses: brew install ncurses
  3. add a symlink for tput where it should be (caution, version specific!): ln -s /usr/local/Cellar/ncurses/6.2/bin/tput /usr/local/bin/
  4. inside my main() function, redefine the PATH so that it prioritizes the Homebrew version over the native one:
    main ()
       # check for brew installed tput for MacOS, backwards compatible with linux/WSL2
       PATH=/usr/local/opt/ncurses/bin/:$PATH
       ...
    

While a hassle for MacOS users, it's an OK enough work around for now.

Leaving this ticket open for maintainers to do with as they please!

@metal3d
Copy link
Owner

metal3d commented May 20, 2023

Right, we should add a requirement check in the script.

@pascalandy
Copy link

pascalandy commented Mar 5, 2024

So, my work around is to:

  1. install Homebew
  2. install ncurses: brew install ncurses
  3. add a symlink for tput where it should be (caution, version specific!): ln -s /usr/local/Cellar/ncurses/6.2/bin/tput /usr/local/bin/
  4. inside my main() function, redefine the PATH so that it prioritizes the Homebrew version over the native one:
    main ()
       # check for brew installed tput for MacOS, backwards compatible with linux/WSL2
       PATH=/usr/local/opt/ncurses/bin/:$PATH
       ...
    

While a hassle for MacOS users, it's an OK enough work around for now.

Leaving this ticket open for maintainers to do with as they please!

I tried but it does not work for me.

I tried this:

# error
$ cd /usr/local/Cellar
no such file or directory: /usr/local/Cellar

# but instead
$ brew --prefix ncurses                  
/opt/homebrew/opt/ncurses

# I feel this should work
$ sudo ln -s /opt/homebrew/opt/ncurses/bin/tput /usr/local/bin/

```

But same result :-/

@mrjones-plip
Copy link
Contributor Author

@pascalandy - sorry my work around didn't work for you! That said, if you did indeed get it installed with brew at the path you specified, then step 4 should still work. Maybe edit your main() function to redefine PATH like so?

PATH=/opt/homebrew/opt/ncurses/bin/:$PATH

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants