Mise À Jour Sept. 2018: vérifiez si le panneau 18.06 a le même problème (il ne devrait pas, après l' moby/moby question 33794, et aussi moby/moby question 35407 et PR 37172, une partie de la 18.06 notes de version).
2016:
L' Ubuntu Dockerfile comprend:
CMD ["/bin/bash"]
Cela signifie que la valeur par défaut ENTRYPOINT est sh -c (et je doute qu' tput line fonctionne bien dans un sh session, depuis tput utilise terminfo de la base de données, qui peut être défini que pour le bash de cette image)
Vous pouvez essayer de remplacer ENTRYPOINT avec bash -c et de vérifier si cela fonctionne mieux.
Qui ne fonctionne pas à partir de la ligne de commande si:
docker run --entrypoint /bin/bash --rm -it ubuntu:16.04 -i -c 'tput lines'
24
Je vais vérifier la possibilité de définir une image personnalisée.
FROM ubuntu:16.04
ENTRYPOINT ["/bin/bash", "-c"]
Le résultat est le même:
docker run --rm -it u 'tput lines'
24
Toutefois, cela "fonctionne":
FROM ubuntu:16.04
ENTRYPOINT [ "/bin/bash" ]
Avec:
docker@default:/c/Users/vonc/prog/testsu$ docker run --rm -it u -i -c 'ls; tput lines'
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
48
Il y a peut être un problème de synchronisation, que la même commande ne retour 24, de temps à autre.
En fait, la suivant toujours le retour "n'24" avec:
FROM ubuntu:16.04
ENTRYPOINT [ "/bin/bash", "-l", "-i", "-c" ]
docker run --rm -it u -c 'sleep 0.1; ls; tput lines'
48
L' OP silgon propose dans les commentaires:
docker run --rm -it --entrypoint /bin/bash ubuntu:16.04 -c "sleep 0.1 && tput lines"
Comme BMitch les commentaires ci-dessous:
Étant donné le succès de sommeil de mes soupçons, c'est que le panneau de tours le récipient avec la commande en cours, et une fois en haut, le client s'attache à l'exécution de conteneur.
Généralement quelque chose qui ne prend que quelques millisecondes.
Cela m'a donné une autre idée:
docker@default:/c/Users/vonc/prog/testsu$
docker run --entrypoint='/bin/bash' --name ub -d -it ubuntu:16.04
0d9b8783afbb5e3ff4232da071d3f357985351ea1ce4d142bf6617ac456fb76b
docker@default:/c/Users/vonc/prog/testsu$
d attach ub
root@0d9b8783afbb:/# tput lines
48
root@0d9b8783afbb:/# exit
exit
docker@default:/c/Users/vonc/prog/testsu$ drmae
0d9b8783afbb5e3ff4232da071d3f357985351ea1ce4d142bf6617ac456fb76b
Un tput lines dans une joint session fonctionne très bien.
(Sur l' drmae alias, voir "Comment enlever les anciens et inutilisés Docker images")
thajeztah ajoute dans les commentaires:
le conteneur est créé, puis a commencé avec les valeurs par défaut (80x24), et par la suite (lors de l' -it), une session est attaché.
La session est de spécifier la taille de la borne;
Voir "Redimensionner un conteneur ATS" de l'API.
DEBU[0244] Calling POST /v1.25/containers/c42fd5c4eb79c06fd7f9912b8359022f7d93887afbb33b57a67ed8bb7bfee43a/resize?h=46&w=221
Pour en savoir plus, voir le panneau question 25450.
Elle est liée à la question 10341 "Conteneur de créer ou de démarrer devrait accepter hauteur/largeur params". Aleksa Saraï (cyphar) ajoute (Sept. 2016):
Ce qui a fait sauté de nouveau à l'intérieur de l'exécution-spec (opencontainers/runtime-spec PR 563).
En gros, depuis Windows requiert la capacité à définir la console de taille au premier démarrage, nous pourrions mettre fin à l'ajouter à toutes les plates-formes.
L' OP silgon points pour le code en api/client/container/run.go:
// Telling the Windows daemon the initial size of the tty during start makes
// a far better user experience rather than relying on subsequent resizes
// to cause things to catch up.
if runtime.GOOS == "windows" {
hostConfig.ConsoleSize[0], hostConfig.ConsoleSize[1] = dockerCli.GetTtySize()
}
Avec la question logique:
serait-il judicieux d'utiliser cette propriété sur Linux en tant que bien, et la console de la taille à l'aide de cette valeur?
Kenfe-Mickaël Laventure (mlaventure) qui est sur elle, et un nouveau patch pourrait-il faire de Docker 1.13.
