How to run a command during a docker build that requires tty?

Question

I have several scripts I need to run during build Docker, which requires tty (which Docker does not provide at build time). Under the hood of the script, the read command is used. With tty, I can do things like (echo yes; echo no) | myscript.sh (echo yes; echo no) | myscript.sh .

Without this, I get strange errors that I don’t quite understand. So is it possible to use this script during build (given that it is not mine to change?)

EDIT: here is a more specific error example:

 FROM ubuntu:14.04 RUN echo yes | read 

which fails:

 Step 0 : FROM ubuntu:14.04 ---> 826544226fdc Step 1 : RUN echo yes | read ---> Running in 4d49fd03b38b /bin/sh: 1: read: arg count The command '/bin/sh -c echo yes | read' returned a non-zero code: 2 

Answer 1

You do not need tty to feed your data to your script. just by doing something like (echo yes; echo no) | myscript.sh (echo yes; echo no) | myscript.sh as you suggested. Also, please make sure you copy the file first before trying to execute it. something like COPY myscript.sh myscript.sh

Answer 2

RUN <command> in the Dockerfile link:

the command runs in the shell, which by default is / bin / sh -c on Linux or cmd / S / C on Windows

let's see what exactly /bin/sh is in ubuntu: 14.04:

 $ docker run -it --rm ubuntu:14.04 bash root@7bdcaf403396 :/# ls -n /bin/sh lrwxrwxrwx 1 0 0 4 Feb 19 2014 /bin/sh -> dash 

/ bin / sh is a dash symbolic link, see the read function in dash :

 $ man dash ... read [-p prompt] [-r] variable [...] The prompt is printed if the -p option is specified and the standard input is a terminal. Then a line is read from the standard input. The trailing newline is deleted from the line and the line is split as described in the section on word splitting above, and the pieces are assigned to the variables in order. At least one variable must be specified. If there are more pieces than variables, the remaining pieces (along with the characters in IFS that separated them) are assigned to the last variable. If there are more variables than pieces, the remaining variables are assigned the null string. The read builtin will indicate success unless EOF is encountered on input, in which case failure is returned. By default, unless the -r option is specified, the backslash ``\'' acts as an escape character, causing the following character to be treated literally. If a backslash is followed by a newline, the backslash and the newline will be deleted. ... 

read function in dash :

You must specify at least one variable.

see the read function in bash :

 $ man bash ... read [-ers] [-a aname] [-d delim] [-i text] [-n nchars] [-N nchars] [-p prompt] [-t timeout] [-u fd] [name...] If no names are supplied, the line read is assigned to the variable REPLY. The return code is zero, unless end-of-file is encountered, read times out (in which case the return code is greater than 128), or an invalid file descriptor is supplied as the argument to -u. ... 

So, I think your myscript.sh script starts with #!/bin/bash or something else but not /bin/sh .

Alternatively, you can modify your Dockerfile as shown below:

 FROM ubuntu:14.04 RUN echo yes | read ENV_NAME 

References:

• https://docs.docker.com/engine/reference/builder/
• http://linux.die.net/man/1/dash
• http://linux.die.net/man/1/bash

Answer 3

Most likely you will not need tty. As the comment on the question shows, even the example presented is a situation where the read command was not called correctly. Tty will turn the assembly into an interactive terminal process that does not translate well into automated assemblies that can be run from tools without terminals.

If you need tty, then the openpty call will appear in the C library, which you will use when formatting a process that includes pseudo-tty. You can solve your problem with a tool like expect , but it has been so long that I don’t remember whether it creates ptty or not. Alternatively, if your application cannot be created automatically, you can manually follow the steps in the running container, and then docker commit resulting container to create the image.

I would recommend against any of them and develop a procedure for creating your application and install it in a non-interactive way. Depending on the application, it may be easier to change the installer itself.