0

I have the following example:

run_docker_script

 #!/bin/bash
argument=$1
if [ argument==c1 ]; then
    DOCKERNAME=container1
else
    DOCKERNAME=container2
fi
docker run -it --rm --entrypoint /bin/bash $DOCKERNAME -c 'read -rp "username:" user'

This is working fine if I call it like ./run_docker_script.sh (means I was asked to give a username).

If I call this script from another one and redirect the output to a file, nothing will be prompted to the console! The script sits there waiting for the input but the user doesn't see anything:

#!/bin/bash

LOG_DIR=results
mkdir -p $LOG_DIR

./run_docker_script.sh c1 >"$LOG_DIR"/result.txt

Any hints?

TunDali
  • 1
  • 1
  • You are simply checking whether `argument==c1` is a nonempty string, which of course it is (though adding quotes around it would make it more obvious). – tripleee May 10 '21 at 16:48
  • You seem to have a space before `#!/bin/bash`, the two characters `#!` must be literally the first two bytes in the file. – tripleee May 10 '21 at 16:50

2 Answers2

0

You are redirecting the prompt to the log file. Probably use tee instead of a plain redirection.

#!/bin/bash

LOG_DIR=results
mkdir -p "$LOG_DIR"  # notice quoting

./run_docker_script.sh arg1 arg2 | tee "$LOG_DIR"/result.txt

You will still probably have some issues with buffering. I'm thinking passing the input as an argument to the Docker container would be a better design.

#!/bin/bash
# ^ notice fixed spacing

if [ argument = c1 ]; then
   #         ^ ^ notice fixed spacing
    DOCKERNAME=debian
else
    DOCKERNAME=ubuntu
fi

read -r -p "username: " username

docker run -it --rm --entrypoint /bin/bash $DOCKERNAME -c "user=$username"

It's slightly weird that Docker outputs the standard error from the shell within the container to standard output, too, but that's what it does. I don't think there is an easy way to change that.

tripleee
  • 175,061
  • 34
  • 275
  • 318
  • There's nothing magic about `argument`, is there? `[ argument = c1 ]` is never true, but then I don't see where a variable called `argument` or `c1` would be set. – Benjamin W. May 10 '21 at 17:14
  • Quite so; I'm imagining they are obscuring the name of a variable like `$1` or something, but didn't want to speculate around that. – tripleee May 10 '21 at 17:17
  • @tripleee : thank you for your feedback. i was aware that some error are available in the script above, it was just a small part from the whole script. changing the script with using "tee" or asking for the input before the "docker run" command will fix my issue but I would like to avoid it. – TunDali May 11 '21 at 08:22
  • because of 2 things: - tee will output everything on the console -> in my case this is too much and I want to avoid it. - Asking for the input is always carried out, that shouldn't be the case either. – TunDali May 11 '21 at 08:33
  • This is probably too obscure to get a good answer. Interacting with something inside a Docker container using the stdin/stdout of the Docker process is just never going to be very robust. A common solution is to run a simple server inside the container, and interact with that over a designated port, for example. – tripleee May 11 '21 at 08:45
0

as i said, the script is working well if i don't redirect the output to a file, means that the user will be asked to provide some input in the console. But if i redirect the output to the file, the text "username:" will be as well redirected to the file and the user doesn't see anything.

TunDali
  • 1
  • 1