This potentially fixes issue #85 by using os.get_terminal_size instead of stty size. This has been tested on linux and on mac os with the expected behavior. This needs to be tested in Windows terminals.
To test the pulling of a resen-core, a resen-core not available on the system was used or an existing resen-core was removed from the system provided that there are no buckets using it, which is to say that there are not docker containers using it. Below an example of removing the docker image associated with resen-core 2020.2.0
list of images:
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
earthcubeingeo/resen-core 2020.2.0 232b82fb464d 6 months ago 3.6 GB
Removing resen-core 2020.2.0:
$ docker rmi 232b82fb464d
Finally a new bucket was created selecting the previously removed or not available resen-core and the expected image pulling mechanism was observed:
Pulling image: resen-core:2020.2.0
This may take some time...
[==============================> ] 98.3 %, 1.209/1.23GB Elapsed t: 0:01:04
As mentioned above, this needs to be tested in Windows terminals to be sure it fixes the problem.
asreimer
commented
3 years ago
This potentially fixes issue #85 by using
os.get_terminal_sizeinstead ofstty size. This has been tested on linux and on mac os with the expected behavior. This needs to be tested in Windows terminals. To test the pulling of a resen-core, a resen-core not available on the system was used or an existing resen-core was removed from the system provided that there are no buckets using it, which is to say that there are not docker containers using it. Below an example of removing the docker image associated with resen-core 2020.2.0 list of images:$ docker imagesRemoving resen-core 2020.2.0:
$ docker rmi 232b82fb464dFinally a new bucket was created selecting the previously removed or not available resen-core and the expected image pulling mechanism was observed:As mentioned above, this needs to be tested in Windows terminals to be sure it fixes the problem.