A Netmiko script runs a maintenance command on a switch that stops mid-run to ask Enter your choice [y/n]: before printing any data, so send_command() keeps waiting for a prompt that never comes back. Which Netmiko call pattern answers that mid-command prompt and still captures the results?
Select an answer to reveal the explanation.
Short Explanation
send_command() waits for the device prompt, so a mid-command question leaves it listening for something that never shows up. send_command_timing() returns as soon as output stops, which is exactly what your switch gives you. It's the difference between knocking until someone answers and just waiting for the room to go quiet — a timing-based read.
Full Explanation
Netmiko's send_command() writes the command and then reads the channel until the expect_string pattern matches, which by default is the device prompt. Because your switch stops at a choice prompt, the reader waits for a pattern that never appears, however long you let it poll. send_command_timing() works differently: it returns whatever has arrived as soon as the channel goes quiet for its interval, so you get the question back, reply with the choice, and read again to collect the results. A larger read_timeout only stretches how long send_command() searches for its pattern and never supplies the missing answer, structured parsing with TextFSM needs complete output before it can build dictionaries, and pointing expect_string at the normal prompt recreates the original hang because that prompt is exactly what the switch is withholding. One caveat: a timing call can return early on a chatty or slow device, so loop the reads until the real prompt appears. A practical check is to print each timing call's return value in the lab and watch the prompt, your answer and the results arrive as separate reads.