Do-nothing scripting: the key to gradual automation (2019)

I&#x27;m a big fan of this approach.<p>In general it&#x27;s another way of defining interfaces around processes. Those processes <i>may</i> be manually done or automated. But the interface can remain the same - this is quite powerful when it comes to automating steps.<p>It&#x27;s the same as you&#x27;d do with another system really.<p>I&#x27;ve used this before with Google sheets being manually filled in -&gt; automated with a script. And with Jira tickets being raised and then automatically picked up and processed. It lets you get started sooner, automated the most annoying parts and you never have to fully do it.<p>Side benefit of do nothing scripts is that they can remain up to date more often as they can be more likely to be actually used than reading the docs.

This is an interesting approach.<p>However the task used as an example just shows how provisionning SSH keys was insecure at that company. In fact the user should generate his private key by himself and just provide the public key to the sysadmin to inject it in the system to grant access. AT NO POINT THE SYSDAMIN SHOULD HAVE A COPY OF THE PRIVATE KEY, even temporary. So the 1Password step shouldn&#x27;t even be necessary.<p>By the way, I&#x27;m the author of github-keygen, a tool to automate the creation of SSH keys dedicated to GitHub access, and to setup SSH settings for that context.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;dolmen&#x2F;github-keygen">https:&#x2F;&#x2F;github.com&#x2F;dolmen&#x2F;github-keygen</a>

I finally tried this an about a year so after it was first posted.<p>Due to bugs in our toolchain we had a run book for hot fixes that was about twice as complicated as the normal release process.<p>I never got the credit it deserved but it went from people only using it for sev 1 issues and “last mile” work in epics that were winding up, say once every ten weeks, to using it on average once a week and a couple times 3 in one week. We were able to dig a lot deeper into tech debt because not every single thing had to be a feature toggle.<p>If you’re at a small company where cloning prod data into preprod is easy, you won’t see this sort of result. But I counted over 150 endpoints we talked to and I believe that averaged 3 per service. So that’s a lot of datasets, and some of them ingested in a Kafka-before-Kafka-existed sort of manner. We had only one guy who would even try to clone prod data, he only had the time (and really energy) to do it once or twice a year, and that was much slower than our customers and features morphed. So it was down to fiddling with the blue-green deployment process and jmeter to figure out if we were close and how to measure success&#x2F;failure before we went live.<p>And in the end it was the fiddly error-prone build process that stymied people until I half-automated it.<p>Later on as we ramped up its use I hunted down all of the URLs for the manual steps and put them in a lookup table in the tool, and ended up exposing them for the normal validation process we did for release sign off as well. Which made that process a little faster and less stressful for the coordinator (that process was annoying enough that we round robined it through three separate teams to share the load)

&gt; It lowers the activation energy for automating tasks<p>Does that mean the &quot;do-nothing script&quot; should eventually have some automated steps that do-something?<p>As a placeholder for future possible automation, this feels like the right balance between automation and efficiency. It allows you to make the first stab without investing too much and it leaves some low-hanging fruit for another time when the effort might be more obviously worthwhile. Thanks for sharing!

<p><pre><code> class Foo(object): def run(self, context): ... </code></pre> Objects with only a single method to run it are already built into Python, they are the functions.<p><pre><code> def foo(context): ...</code></pre>

It&#x27;s great, but it can&#x27;t be interrupted.<p>It would also be nice if it would show you all the steps beforehand, and then check each item as you progress. Sometimes it&#x27;s good to actually prepare from a broader perspective.<p>And it could log into a file as a summary.<p>So much that could be improved, which is why the simplest solution might be the best.

Past discussions (lots of comments):<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29083367">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29083367</a> - 3 years ago (230 comments)<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20495739">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20495739</a> - 6 years ago (124 comments)

I cannot overstate how big a fan i am of this approach.<p>I&#x27;ve successfully applied this approach to so many projects. My favorite example is a $30 million surgical robot that was failing labs because of the &quot;human factor&quot;.

I love this approach. I already like doing this in systems above a certain complexity made with programming languages too. I think the functional programming community calls this &quot;holes&quot;?<p>Interface &quot;not implemented&quot; errors follow a similar logic but I honestly think the value of writing something trivial that gives a meaningless but valid output for each of a bunch of pieces that depend on each other goes a long way toward expediting the process of building those pieces. It makes it much more likely you can test and build one thing at a time and not need to write a bunch of separate parts before you can test any of them<p>Having this type-wise validity matter in scripting contexts is sometimes harder, as in the use case described in the article, as a lot of the effects of command lines are going to be &quot;side effects&quot; from a functional perspective, but it being sequential makes this a lot less impactful and the waiting prompts make it so you can still preserve order of tasks at the low cost of needing manual steps you&#x27;d be doing without the script anyway<p>Scaffolds are incomplete but they&#x27;re still, fundamentally, useful

While I like this in theory, I think it would have trouble in practice. If an ops team is doing the same task over and over, and they see the do-nothing script does nothing, they will quickly stop using it once they think they’ve memorized the steps, or if they think it’s faster (or more interesting) to do it manually.<p>I’ve written a lot of automation and documentation for ops teams and getting them to use it, and use it constantly, has always been an issue. Doc changes also needed announcements, as people quickly stop reading them once they know how to do something.<p>In a perfect world, I think the approach makes a lot of sense, and I might even use it for some personal stuff. In practice the world is rarely perfect, and I think I’d only employ this if 90% was automated, but there was still 1 step I couldn’t quite get… and even then, I could see some members on the ops team skipping the manual step and assuming the whole thing is automated and magic.

Ideally this documentation would also document the expected output, both toward identifying when the process has gone off the rails when doing it manually and making the steps testable once automated.<p>Otherwise, it&#x27;d be trivially easy for an unfamiliar user (or the automated script) to ignore unclear errors or exit codes and march blindly to the next wait_for_enter().

1. Write the runbook<p>2. Automate the runbook<p>3. Delete the runbook<p>This is just a means to get #2 done iteratively. I&#x27;ve done variations for a while, its a powerful technique.

This is, to a degree, how I’ve always written my SOPs. If anything, this approach is encouraging me to make two changes to my documentation approach:<p>1) Add a “Quick Run” section with just the steps&#x2F;commands absent images and details, so it’s easier to perform routine slogs without having to scroll through unnecessary information.<p>2) Make (and link!) a companion code document that has the pseudocode for the process written out, so folks can contribute to it as time allows. If I’m a manager, I’d even incentivize it somehow - maybe covering a team lunch if we convert an SOP into an automation, for instance.<p>In the meantime, I am totally cribbing this for documenting my homelab stuff and getting it out of Obsidian, as a means of encouraging me to automate routine tasks somehow.

This same is also known by another name when it&#x27;s used to teach new programmers: pseudo code.<p>Sadly, because it&#x27;s associated with learners&#x2F;juniors, pseudo code gets a bad rap. But really, <i>all</i> engineering is translating English into code ... which means almost <i>any</i> complex operation (setting up a new employee&#x27;s account, or anything else) can be made clearer by utilizing such an &quot;in-between English and code&quot; step.<p>In the article they used Python, but for all the important stuff, they didn&#x27;t: they used English. A &quot;do-nothing&quot; script is really just a script where instead of converting pseudo code to code (like programmers normally do), you just leave the English&#x2F;pseudo code in, and wrap it with a print.

I love this! it encourages you to mentally define the steps. To me, the next step is to define the &quot;inputs&quot; and &quot;outputs&quot; that each step should have. Next after that in many cases would be &quot;what to do or just what to suggest to the user if each of the steps fail.&quot; And at that point you have not only a nicely already function-based outline if you want to make it a real automation.<p>It&#x27;s a thought technology which I suspect will result in better final scripts than what I have tended to do, which is much more linear and requires a significant refactoring step at the end to avoid having one long function of poor quality.

The author needs to watch my buddy Jack&#x27;s talk: Stop Writing Classes: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;o9pEzgHorH0?si=FgZqFGQNQUU2iREQ" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;o9pEzgHorH0?si=FgZqFGQNQUU2iREQ</a>

One Note is good for this, it doesn’t have to be a do-nothing script.<p>One Note also has the ability to add checkboxes as dot points, and you can make “template pages” for each procedure and then you can then just right click -&gt; duplicate, and use the checkboxes to keep track of where you get upto in a process.<p>The reason this is great for me is because I virtually never get to sit still and finish anything unless it takes less than 1 min. People pull my attention in every direction.

I bet you could adapt this for orchestrators besides a script. For instance if the goal is to eventually have it all running in Airflow, you could have a do-nothing DAG, which would be nice because your co-workers could see that you&#x27;re already half-way through today&#x27;s task, whereas separate python scripts don&#x27;t know about each other. You could just use a `sleep infinity` to keep the task &quot;running&quot; until somebody manually sets it to &quot;success&quot;.

I wrote a simple LLM tool that helps generate such scripts.<p>Tool: <a href="https:&#x2F;&#x2F;tools.o14.ai&#x2F;do-nothing.html" rel="nofollow">https:&#x2F;&#x2F;tools.o14.ai&#x2F;do-nothing.html</a><p>Blogged about here: <a href="https:&#x2F;&#x2F;shekhargulati.com&#x2F;2025&#x2F;02&#x2F;16&#x2F;do-nothing-script-generator&#x2F;" rel="nofollow">https:&#x2F;&#x2F;shekhargulati.com&#x2F;2025&#x2F;02&#x2F;16&#x2F;do-nothing-script-gener...</a>

I do this for some yearly tax stuff, as the big issue for me is that it was a year since I did it last and getting started with a complex and boring thing is hard<p>So I built a script that tells me what the first step is. When it&#x27;s done I run the script again and it tells me what to do next. Often the first few steps are &quot;download this CSV from the bank&quot; so the script can detect I&#x27;ve done than and go directly to the next step when I rerun the script<p>The reason I have a script I rerun rather than a &quot;press enter to continue&quot; is because it then only keeps persistent state, and I can easily do a bit every day until done<p>A common pattern is<p><pre><code> if ! [[ -e checked-all-the-receipts ]]; then echo &quot;check that the receipts match the list of expenses, then&quot; echo &quot; touch checked-all-the-receipts&quot; exit 0 fi </code></pre> Then over time, I have automated some parts and added some checks. E.g. when I have downloaded a CSV I can check that the format looks right before considering the step done. I&#x27;ve added some autogeneration of documents I need, built a python script to add up transactions and check the that the totals match etc

I would use a checklist for that. Most wiki&#x2F;notes&#x2F;todo software supports checklists or checkboxes. It has the benefit that you can still see all steps at once, perform some steps out of order if the dependency isn’t linear, and it can be simply part of your process documentation instead of having to find and run a script. It’s also easier to edit.<p>The article even mentions “just another checkbox checked”.

Even though “toil” is a term of art, be careful using it around executives who are not SMEs.<p>I once saw an SRE get managed out because he kept talking about “reducing toil” and his director eventually said, “he obviously didn’t like toiling here so we helped him leave.”

This approach always sounds great upon initial consideration but has a fatal flaw. It doesn&#x27;t scale because people are lazy. Over time, slogs will always revert to their original form.

Yeah, I started to incorporate this into my own work.<p>Like, sometimes you can automate 99% of a procedure, except like putting a secret into an so-far not automated secret management solution, or running a terraform apply that requires access to something that&#x27;s not accessible from the automation just yet.<p>Instead of giving up there, I now just go ahead and insert e.g. an `ansible.builtin.pause` with clear instructions to the user what to do, and when to continue the play. This might not be gloriously fully automated (yet), but it is so much better than having to do the other 12 things manually.<p>Similar, we have &quot;standard plays&quot;, which are just shell scripts to invoke ansible in some specific way. But those have started to accrue some user guidance and some do-nothing instruction steps as well. The database creation script asks you if you&#x27;ve added the database in the three other places upon startup, since it&#x27;d fail otherwise. Or a disk resize standard play asks you if you need to resize the disk on a failover cluster as well now?<p>I would like to have these things fully automated, but having these simple scripts as guidance for admins is surprisingly valuable.

Haven&#x27;t had my coffee yet but this strike me as, &quot;reinvent the Makefile&quot;. Which I have certainly used as a place to codify steps with benefits.

It&#x27;s not a &quot;do nothing&quot; script at all! The script encodes a high-level workflow, which is crucial, mission-critical information. It doesn&#x27;t really matter what &quot;runs&quot; the steps, you can assume it&#x27;s an agent of some sort. Sometimes that role is played by a human person, sometimes not.

Then it really isn&#x27;t doing nothing. Rather, it&#x27;s a to-do app in the terminal.<p>The reason it is helpful for decreasing activation energy is that it handles the &quot;checklist&quot; aspect of creating a user account for you. This is especially helpful for user account creation, which has to be done completely and then logged or it can lead to cybersecurity incidents.

I should just do this for waking up so that I won&#x27;t be confused on my morning routine. In a sense, it&#x27;s a rudimentary slide show

I did something like this but it helps you build exact command lines or interact with AWS straight from your GitHub markdown. As a bonus, it very easily lets you prompt the user for inputs and pivot between different accounts. <a href="https:&#x2F;&#x2F;speedrun.cc" rel="nofollow">https:&#x2F;&#x2F;speedrun.cc</a>

I found this a few years ago and was quite inspired by it. I then more recently found <a href="https:&#x2F;&#x2F;xcfile.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xcfile.dev&#x2F;</a> which is a great way to implement these sort of scripts directly in the project&#x27;s README.

In my time we called that a &#x27;checklist&#x27;. We used it for overcomplicated build procedures in some forsaken Microsoft toolchain that did not have build automation, and which spanned several different systems that were firewalled off from each others.

The biggest hold up in automation for me usually are things that need to be done via a gui.<p>I tried automatizing those with some tools intended for gui testing, but those solutions tend to be brittle and I just don’t feel well if I cannot get a real success report.<p>I’d be fretful for somthing that solves that problem.

We taken this approach using streamlit to incrementally turn Markdown lists of instructions into mini, self-service web apps. Steps in lists are gradually replaced with widgets, collecting inputs for the automation to do the work instead.

I like this way of thinking. I’m working on a bunch of automations right now and using GitHub actions.<p>I find the idea of setting up “do nothing workflows” that I can compose and implement more thoroughly over time helpful. I’ll probably put this into use.

My variant of this is putting the manual steps in between scripted steps as a comment, but having read the article I can see the benefit of this approach.<p>In PowerShell especially there are elegant ways to prompt users for “continue y&#x2F;n?”.

In 2025, this is insane. With Aider + $10 of credit on OpenAI, I can tell Aider to make this same script and it will actually make it do something.

SWE version of a checklist?

This is actually brilliant. This is a step above every list of instructions that I&#x27;ve ever made without committing to full-blown all-at-once automation.

I’ll probably get down voted to oblivion, but this is really silly. I do not see any value proposition. To each their own, I guess.

<a href="https:&#x2F;&#x2F;www.pyinvoke.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.pyinvoke.org&#x2F;</a>

Has anyone here successfully (or not) implemented BPMN for this kind of process management?

To be clear; you&#x27;re supposed to have a separate shell open where you do these steps?<p>MM, interesting idea.

A good way of documenting processes for people that prefer to look at code than long PDfs

Great in theory until some error or problem comes up and you don’t know how to handle it.

Kinda sounds like a &quot;TBS-driven&quot; approach. Certainly helpful.

I was looking for this article recently since it inspired my most recent script to POSSE to various websites [0]. Thanks for posting it again!<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;MattSayar&#x2F;post_to_socials">https:&#x2F;&#x2F;github.com&#x2F;MattSayar&#x2F;post_to_socials</a>

do each of the steps, as an object, look overengineered?<p>I follow the advice of this column, but I differ in my implementation. It is lightweight and not so OO.

I don&#x27;t get why it&#x27;s such a big deal

Oh yeah! I&#x27;ve seen this pattern used at work. I don&#x27;t have an opinion on if it is better than a checklist. The lack of will or time to automate affects a do nothing script as much as runbook.

While the idea of it is nice, I&#x27;ve never actually used it more than once or twice. Instead I write runbooks in Confluence, and that evolves over time.<p>Confluence is fantastic for runbooks. It&#x27;s accessible to all kinds of users, you don&#x27;t have to grant access to them, you get comments, people can edit on the fly without a review, the content is versioned, and most importantly, includes mixed media. My runbooks are often a mix of video clips, screenshots, text, and links to other pages.<p>In order to automate the runbooks, I do a couple things:<p><i>1)</i> I write little scriptlets and either drop them into the runbook as one-liners, or commit them to a `.&#x2F;bin&#x2F;` directory in a repo with some basic documentation. <i>1a)</i> If I write a script, usually I make it so it takes some arguments and produces output, so that it can be modified later in a backwards-compatible way, and so it can be composed-with. Every time I do this, I&#x27;m making automation easier later on.<p><i>2)</i> I have a deployment wrapper `deploy.sh`, and a CI&#x2F;CD job that calls the wrapper. If I make my scriptlets call-able from `deploy.sh`, then my scriptlets get to take advantage of all the environment set-up my CI&#x2F;CD job did, so I don&#x27;t have to do any more work to get the CI&#x2F;CD system to call my scriptlet. And since my CI&#x2F;CD job can take parameters and pass them onto `deploy.sh`, and `deploy.sh` can pass arguments to my scriptlet, and my scriptlet can take arguments, I can now re-use the one CI&#x2F;CD job I made, to call my scriptlet, from any CI&#x2F;CD pipeline, or from a one-time API call to the CI&#x2F;CD provider with parameters.<p><i>3)</i> I have a Slack bot that&#x27;ll take commands from Slack and call the CI&#x2F;CD job with parameters. Now I&#x27;m enabling chat users to call automation from Slack, reusing the CI&#x2F;CD, reusing the deploy.sh, reusing my scriptlets, enabling users to call automation from their chat window.<p><i>4)</i> I modify the Slack bot to allow users to edit cron jobs (really just scheduled CI&#x2F;CD jobs) to run tasks on a regular basis. Now they can either use pre-written scripts, or write their own, and schedule them to run regularly.<p>Now, my day job has quite a few different responsibilities (as all Sysadmi-<i>cough</i> I mean &quot;DevOps Engineers&quot;- tend to have), so I don&#x27;t have time to build all this in one go at each job I work at. I build the whole thing slowly over time. As each new feature is available, I release it for use: first the Confluence runbooks, then the scriptlets, then the CI&#x2F;CD jobs, then the Slack bot. It takes about two years for all of it to be ready. But once it is, it&#x27;s amazing how much productivity a whole team of people gets out of it.<p>If I was allowed to do all this automation at once, we&#x27;d reap the benefits much sooner. But people who have never seen the rewards of automation never prioritize it.

Just did a slightly more elaborate version (mostly colors)<p>run it with `uv run --script script.py`<p><pre><code> #!&#x2F;usr&#x2F;bin&#x2F;env -S uv run --script # &#x2F;&#x2F;&#x2F; script # requires-python = &quot;&gt;=3.13&quot; # dependencies = [ # &quot;rich&quot;, # ] # &#x2F;&#x2F;&#x2F; # run using `.&#x2F;script.py` or `uv run --script script.py` import argparse from rich import print from rich.prompt import Prompt from rich.panel import Panel def print_title(text): print(Panel(f&quot; {text}&quot;, style=&quot;green&quot;)) print(&quot;\n&quot;) def print_desc(text): print(f&quot;[yellow] {text}[&#x2F;yellow]&quot;) def print_command(text): print(f&quot;[white]{text}[&#x2F;white]&quot;) def user_input(prompt): print(&quot;\n&quot;) return Prompt.ask(f&quot;\n[red] {prompt}[&#x2F;red]&quot;) def wait_for_enter(dummy_flag): print(&quot;\n&quot;) print(Panel(f&quot; Press enter to continue&quot;, title_align=&quot;center&quot;, style=&quot;blue&quot;)) input() class CreateSSHKeypairStep: def run(self, context): print_title(&quot;Generating SSH Key Pair&quot;) print_desc(&quot;Run:&quot;) print_command(f&quot;ssh-keygen -t rsa -f {context[&#x27;key_path&#x27;]}&#x2F;{context[&#x27;username&#x27;]}.pub&quot;) wait_for_enter(True) class GitCommitStep: def run(self, context): print_title(&quot;Committing SSH Key to Git Repository&quot;) print_desc(&quot;Run:&quot;) print_command(f&quot;cp {context[&#x27;key_path&#x27;]}&#x2F;{context[&#x27;username&#x27;]}.pub user_keys&#x2F;&quot;) print_command(f&quot;git commit {context[&#x27;username&#x27;]}&quot;) print_command(&quot;git push&quot;) wait_for_enter(True) class WaitForBuildStep: build_url = &quot;http:&#x2F;&#x2F;example.com&#x2F;builds&#x2F;user_keys&quot; def run(self, context): print_title(&quot;Waiting for Build Job to Finish&quot;) print_desc(f&quot;Wait for the build job at {self.build_url} to finish&quot;) wait_for_enter(True) class RetrieveUserEmailStep: dir_url = &quot;http:&#x2F;&#x2F;example.com&#x2F;directory&quot; def run(self, context): print_title(&quot;Retrieving User Email&quot;) print_desc(f&quot;Go to {self.dir_url}&quot;) print_desc(f&quot;Find the email address for user `{context[&#x27;username&#x27;]}`&quot;) context[&quot;email&quot;] = user_input(&quot;Paste the email address and press enter&quot;) class SendPrivateKeyStep: def run(self, context): print_title(&quot;Sending Private Key&quot;) print_desc(&quot;Go to 1Password&quot;) print_desc(f&quot;Paste the contents of {context[&#x27;key_path&#x27;]}&#x2F;{context[&#x27;username&#x27;]} into a new document&quot;) print_desc(f&quot;Share the document with {context[&#x27;email&#x27;]}&quot;) wait_for_enter(True) if __name__ == &quot;__main__&quot;: parser = argparse.ArgumentParser(description=&quot;Automate SSH key setup and sharing process.&quot;) parser.add_argument(&quot;username&quot;, type=str, help=&quot;Username for whom the SSH key will be generated&quot;) parser.add_argument(&quot;--key-path&quot;, type=str, default=&quot;.&quot;, help=&quot;Path where the SSH key will be stored (default: .)&quot;) parser.add_argument(&quot;--extra-args&quot;, nargs=&quot;*&quot;, help=&quot;Additional arguments for future use&quot;) args = parser.parse_args() context = { &quot;username&quot;: args.username, &quot;key_path&quot;: args.key_path, &quot;extra_args&quot;: args.extra_args or [] } procedure = [ CreateSSHKeypairStep(), GitCommitStep(), WaitForBuildStep(), RetrieveUserEmailStep(), SendPrivateKeyStep(), ] for step in procedure: step.run(context) print(&quot;[green] Done.[&#x2F;green]&quot;)</code></pre>

A lot has changed since 2019. That &quot;do nothing&quot; script can be fed to an LLM and it&#x27;s going to be a pretty good starting point for automating it. For example, feeding the script to ChatGPT o3-mini-high produced this for one of the steps:<p><pre><code> class CreateSSHKeypairStep(object): def run(self, context): keyfile = os.path.expanduser(&quot;~&#x2F;{0}_ssh_key&quot;.format(context[&quot;username&quot;])) pubkey = keyfile + &quot;.pub&quot; if os.path.exists(keyfile): print(&quot;Key file {} already exists. Skipping generation.&quot;.format(keyfile)) else: print(&quot;Generating SSH key pair (no passphrase) in {} and {}.&quot;.format(keyfile, pubkey)) cmd = [&quot;ssh-keygen&quot;, &quot;-t&quot;, &quot;rsa&quot;, &quot;-f&quot;, keyfile, &quot;-N&quot;, &quot;&quot;] subprocess.check_call(cmd) # Save the key filenames in the context for later use. context[&quot;keyfile&quot;] = keyfile context[&quot;pubkey&quot;] = pubkey wait_for_enter()</code></pre>

This is a waste of energy as there a cleaner clearer more effective ways of dealing with this script. You can go much cleaner and just do a Markdown Slideshow. Alternatively allow for a little real automation and use something like Expect or Pexpect.<p><a href="https:&#x2F;&#x2F;pexpect.readthedocs.io&#x2F;en&#x2F;stable&#x2F;overview.html" rel="nofollow">https:&#x2F;&#x2F;pexpect.readthedocs.io&#x2F;en&#x2F;stable&#x2F;overview.html</a><p>Don&#x27;t pretend to yourselves that presenting a series of instructions and only advancing on when someone clicks enter will prevent people hit enter.<p>Even worse is someone missed up there&#x27;s no going back. You have to either restart the whole process or you have to go and read over the python script.<p>This is not something that prevents or helps with slog.