1

My question is whether it is possible to edit the crontab of a WSL2-based instance of Ubuntu with my Windows VSCode that is connected via WSL remote SSH.

If I type export EDITOR=code inside my WSL instance and then crontab -e, I am able to see a /tmp/crontab.sygFAU file load inside my VSCode instance.

The problem is that once I make edits to this file, it will save the file to /tmp/crontab.sysFAU but it doesn't actually take the next step of replacing the the real crontab file in /var/spool/cron/crontabs.

So once I re-open the crontab, it will just show what I had previously, and not my saved edits.

It would be nice to know if this is not possible or if there are any alternative ways to run a GUI editor because using nano is a pain!

NotTheDr01ds
  • 15,620
  • 5
  • 44
  • 70
xt1xty
  • 13
  • 2
  • Welcome to Stack Overflow! Just a heads-up that this is *borderline* off-topic, but since you ask about VSCode (clearly a programming tool), I'm going to give it a pass (personally). However, since you *also* are willing to accept *"any easy GUI alternatives"*, it could certainly be considered "non-programming". Just for future reference, consider that questions like this *might* be a better fit for [Super User](https://superuser.com) or [Ask Ubuntu](https://askubuntu.com) (both sister sites of Stack Overflow -- You can even use the same login you created here). Thanks! – NotTheDr01ds Dec 17 '22 at 00:42

1 Answers1

0

An interesting question that I haven't considered before, myself. Here's what's happening:

  • You set your editor to code

  • You crontab -e, which properly loads VSCode with the temporary crontab.

  • However, because this is a Windows GUI application, it returns control to the parent Linux application (crontab) immediately after starting VSCode. You can see the same result if you just start notepad.exe from your shell in WSL -- Once Notepad starts (rather than exits) control is returned to the shell.

  • If you switch back to your terminal at this point, you'll see that crontab detected that the editor that it launched exited (returned), and so it has already tried to copy the temporary file to the permanent location.

  • However, since the temporary files doesn't yet have any changes, crontab decides there's nothing to do.

  • Editing the file in VSCode and saving it has no effect, other than to leave a dangling /tmp/... file hanging around (since crontab isn't there to clean up).

So what's the solution? We need a way to launch a Windows GUI application and prevent it from returning control to crontab until you are done editing.

I originally thought something from this question might work, but the problem is that the actual command that launches the Windows process is embedded in a shell script, which you can see with less "$(which code)" (or code "$(which code)"), but it's probably not a great idea to edit this.

So the next-best thing I came up with is a simple "wrapper" script around the (already-a-wrapper) code command. Create ~/.local/bin/code_no_fork.sh (could be anywhere) with:

#!/usr/bin/env bash
code $* > /dev/null
echo Press Spacebar to continue
read -r -s -d ' '

Credit: This answer for the Spacebar approach

Then:

EDITOR=~/.local/bin/code_no_fork crontab -e

After you make your edits in VSCode, simply press Space to allow the script to continue/exit, at which point crontab will (assuming no errors were detected) install the new Crontab.

Alternatives

This is should typically only be a problem with Windows GUI applications, so the other possible avenue is to simply use any Linux editor that doesn't fork. If you want a GUI editor, that's entirely possible as long as you are running a WSL release that includes WSLg support (now available for Windows 10 and 11).

I won't offer any individual editor suggestions since that would get into "opinion" and "software recommendation" territory, which is off-topic here.

NotTheDr01ds
  • 15,620
  • 5
  • 44
  • 70