Im facing an issue with how the log in docker compose looks like, seems somehow broken as shown below

picture here

==> Emulator is ready : '1' is not completely override the previous output "please wait" as you can see.

also the previous output is not being displayed in the output not sure why, here is my shell script function i have wrote

function check_emulator_status () {
  printf "${G}==> ${BL}Checking emulator booting up status 🧐${NC}\n"
  start_time=$(date +%s)
  spinner=( "⠹" "⠺" "⠼" "⠶" "⠦" "⠧" "⠇" "⠏" )

  while true; do
    result=$(adb shell getprop sys.boot_completed 2>&1)

    if [ "$result" == "1" ]; then
      printf "${G}==> \u2713 Emulator is ready : '$result' ${NC}\n"
      adb devices -l
      adb shell input keyevent 82
    elif [ "$result" == "" ]; then
      printf "${YE}==> Emulator is partially Booted! 😕${NC}\r"
      printf "${RED}==> $result, please wait ${spinner[$i]} ${NC}\r"
      i=$(( (i+1) % 8 ))

    current_time=$(date +%s)
    elapsed_time=$((current_time - start_time))
    if [ $elapsed_time -gt 240 ]; then
      printf "${RED}==> Timeout after 3 minutes elapsed 🕛.. ${NC}\n"
    sleep 0.2

1 Answer 1


\n is not supposed to clear to the end of the line, but leave the contents unchanged. The standalone command

printf 'abcdef\rghi\n'

ends up printing ghidef and not ghi, that's by design. \r moves the cursor to the beginning of the line, ghi overwrites abc, but def stays there.

To clear to the end of the line you can use the \e[K (erase in line) escape sequence. So this command ends up displaying ghi:

printf 'abcdef\r\e[Kghi\n'

(Note: Emit \e[K at the beginning of the line, rather than at the end of the new text, because there's a confusion how the sequence should behave if the cursor is just about to wrap to the next line. In other words, you might encounter a visual glitch if the new text happens to be just as wide as your terminal. The exact behavior even varies across terminal emulators.)

To further complicate the story, the things you print apparently don't go directly to the terminal but somehow some Docker component prepends the cyan test | text. The engine which does this prepending apparently isn't prepared for properly handling \r, so chances are you cannot achieve the "correct" behavior of overwriting previous output. If this theory is confirmed then it might be worth a feature request against the piece of software that does this; it shouldn't be hard for that software to re-print that test | after a \r.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.