ipython
handling implicit prompt request in run time like colab
I've recently encountered this problem that when my code has an implicit user input request, the Jupiter notebook isn't able to handle it and the kernel just keeps running until I manually interrupt it. If I explicitly use an input or read command the kernel will ask me for user input while running in a cell and the problem is for command requiring input without asking explicitly.
The google colab can handles such a situation without any problem and I'm asking for a magic command to do the same in Jupiter notebook and jlab. consider the following example which doesn't have any explicit input or read function associated with it:
!touch something.txt
!rm -i something.txt
If I run this code in colab, a prompt will come up and ask me if I want to delete something.txt. However, if I run the same code in jlab, the kernel keeps running in that cell and I get no prompt or any other output until I interrupt the kernel manually!!
- So, this is a feature request for a new magic command or native support to watch for implicit input requests in run time, similar to what colab does natively without any magic.
- The original problem was mentioned here
- a StackOverflow question regarding this problem was asked here
I'm curious how colab can do this. I don't know of a way to run a subprocess like a bash command and figure out when it has blocked on stdin.
@jasongrout I'm also very curious about this feature of colab!! Isn't there any github repo or some similar place that we could ask its developers?
@jasongrout I also got an idea from your saying that
a way to run a subprocess like a bash command and figure out when it has blocked on stdin
and searched StackOverflow and found this which I don't know how helpful or even relevant it is. I appreciate it if you could look at it.
I found a workaround to temporarily achieve the functionality of answering prompts, I explain steps in case anyone else has the same problem:
- Use IFrame to open an interactive terminal in a notebook cell:
- install
TermRecordto record all the commands and outputs in a static HTML file - write your code
- use another IFrame to see the recorded commands in a new cell
from IPython.display import IFrame
IFrame(src="http://localhost:8888/lab/workspaces/terminal", width="100%", height="400px")
# SHELL COMMAND
##$ TermRecord -o session.html
##$ <YOUR COMMANDS>
##$ exit
IFrame(src="../session.html", width="100%", height="300px")
You can just use the interactive terminal and do your work but I think the whole point is to document your code and its output in a notebook, and TermRecord is one of many shell apps that provides this functionality.
Finally, I hope we can have this prompt responsiveness in jlab in near future which makes the experience of using a notebook more unified and complete.
@jasongrout recently I was using colab and I was installing some conda packages. Something seemed strange, I guess every time that something was running slow enough for the prompt to stay on it there was an input box adjacent to that run time shell message. At that moment, I thought I may have figured out how colab can find input prompts. I believe it doesn't look for input prompts but it prompts an input box for every new line in run time shell messages and closes that box when the next line is printing. So, if the command needs an input it will only go to the next line when the user writes the input and pushes the enter or some other key on the keyboard but if it doesn't need an input there are two situations, when the scripts run super fast which we can't see any input box, there was an input box but the speed of its coming and going was faster than we could see it, and the second scenario is when the command is running slowly, which it shows an input box but because the program doesn't expect any input it doesn't do anything if you input something (like what happens if you press enter in the shell while something is running)!! What do you think?
What do you think?
Wow, that's an interesting idea! Perhaps there could be a minimum wait time too, like 1/2 second or something, to avoid flickering, but be short enough to be fairly imperceptible? It sounds like an interesting idea to try.
I don't think colab does that because the box stays active even if the process takes hours to run (I just checked that with a command which was running for almost two hours). However, why not! we can do a better job. I guess there could be a timing option to make it more sophisticated! The other issue is that I guess this process is inefficient to be always active whenever a shell command is running. It would be better if there was an alias or something like a modified version of ! which could specify when we need to check for prompt compare to when we just need to run a command and there is no need for a prompt.
I don't think colab does that because the box stays active even if the process takes hours to run (I just checked that with a command which was running for almost two hours). However, why not! we can do a better job.
I meant that when we have a stdout line, don't immediately append a stdin box. Instead, wait 1/2 second or something before showing a stdin input box.
The other issue is that I guess this process is inefficient to be always active whenever a shell command is running. It would be better if there was an alias or something like a modified version of
!which could specify when we need to check for prompt compare to when we just need to run a command and there is no need for a prompt.
Oh, nice. Though for me, I would probably forget this as much as I forget to put -y in !conda install mypackage, so I'm not sure it would be any less frustrating to always remember whether I wanted stdin processing or not, and change my command if needed.
I meant that when we have a stdout line, don't immediately append a stdin box. Instead, wait 1/2 second or something before showing a stdin input box.
Oh, I misunderstood! So, I guess this 1/2 second would be an intermediate choice between always instantly active input box, like colab, or having an alias, my idea.
I just want to throw out my support for this feature. Literate bash programming is pretty impossible without it
+1 for this feature, this would be essential. I had to move to colab as a workaround.
