Learn Docker With My Newest Course

Dive into Docker takes you from "What is Docker?" to confidently applying Docker to your own projects. It's packed with best practices and examples. Start Learning Docker →

Wait for Input in a Graphical Code Editor in a Shell Script

blog/cards/wait-for-input-in-a-graphical-code-editor-in-a-shell-script.jpg

For example, your script might launch VSCode and wait for a file to be edited and then do something once the file is closed.

Quick Jump: Demo Video

If you have a command line tool where you do something like this:

#!/usr/bin/env bash

# ...

vim myfile

# TODO: Logic to check if the file changed and then do something. This can be
# whatever you want to do. You could get the md5 checksum of a file before
# and after the file was edit and compare the values to see if they changed.
# Alternatively you can compare the modified time of the file instead.

It’s easy to handle this because your script will launch Vim in the same terminal as the script and then once the user exits Vim your script will resume execution.

But what if you want to make your tool more user friendly and instead of launching vim you want to launch $EDITOR which is the user’s configured code editor of choice?

Perhaps they’re using a graphical code editor like VSCode, Sublime Text, PHPStorm, Kate or something else.

Now we have a use case where your script will launch an external graphical tool but you don’t want to continue execution of the script until the user closes the file in their editor.

Fortunately most graphical editors have the concept of a “wait” flag which waits until a file is closed before returning. Closed in this case could be closing the file’s tab in your editor or closing the editor itself.

Here’s the wait flag for a few graphical code editors. You can find more by Googling:

code --wait
subl --wait
phpstorm --wait
kate --block

After launching your editor with this flag to edit a specific file you’ll notice that the command doesn’t immediately return in your terminal. Instead it will remain open until you close the file you opened.

Now you can adjust your script to be like this:

#!/usr/bin/env bash

# TODO: Add logic to detect `$EDITOR` and add a specific --wait flag to it if
# it's needed, this way your command works for more folks out of the box.

# ...

${EDITOR} myfile

# ...

The workflow ends up looking like this:

  • User runs your command line tool
  • Your tool opens the file in their configured code editor
    • If the editor is already open it may open a new tab with the file
  • User chooses to modify or not modify the file and closes the file in their editor
    • Your tool’s execution will halt execution until they close the file or editor
  • Your tool resumes execution

The video below demonstrates how this works.

Demo Video

Timestamps

  • 0:11 – Demoing how it works
  • 0:48 – Real world use case
  • 1:22 – It works as is with terminal editors
  • 1:54 – Demoing the problem with graphical editors
  • 3:53 – Using the wait flag with most graphical editors
  • 5:18 – Testing the EDITOR environment variable
  • 5:55 – If your editor is open, it may spawn a new tab

What type of scripts have you created where you did this? Let me know below.

Never Miss a Tip, Trick or Tutorial

Like you, I'm super protective of my inbox, so don't worry about getting spammed. You can expect a few emails per month (at most), and you can 1-click unsubscribe at any time. See what else you'll get too.



Comments