Skip to content
Zide Zide

Script Runner

You can use the Script Runner to auto-detect and run scripts, and to build targets and executable programs in your project. Use the Script Runner to run your favorite scripts instead of repeatedly typing the same commands.

To show the Script Runner activity, click its activity-bar icon or click Tools > Script Runner.

The activity has two modes, chosen with the Scripts / History toggle in the header. Scripts is where you browse and launch (Favorites + the Scripts and Programs list); History is your run log.

To choose the shell your scripts run in, click the Shell for script runs button (the terminal icon next to the Scripts and Programs heading). The choice is saved per project. With Default selected, script runs use the Default Shell from Settings, or the system default if none is set.

Favorites

You can favorite scripts to pin them at the beginning of the Scripts mode. To favorite a script, click the Add to favorites icon in the Scripts and programs section.

History

Switch to History for a single, flat log of your past runs, newest first — every run (including favorited ones), by date and time, with no collapsing. Each entry shows its status (a green check for success, a red x with exit N for a failure, or a neutral minus when the exit code could not be determined), the target name and source, how long the run took, and how long ago it ran. Failed runs auto-expand with their log visible, so the error is in front of you without digging. Per-entry controls let you run it again (with the exact command that was recorded — for example a specific MSBuild configuration or a Rebuild), open its output (click the entry to expand its build log inline, or open the saved log in a file tab), and remove it. History is retained on disk (roughly the last 20 runs per script, up to a 100 MB cap), and Clear empties it.

Re-running an entry whose script is no longer detected (for example, its folder is now skipped by the scan) tells you it is no longer detected rather than doing nothing.

Recently built executables

Your most recently built executables are available in the Scripts and Programs list by choosing the Recent sort (List view), which floats programs to the top newest-built first.

Click a run output to expand the row. The expanded run output row displays the full build log of the run.

Scripts and programs

You can view all scripts and programs available in a repository. Scripts and programs are listed alphabetically. Click the Rescan for scripts icon to refresh the list of scripts.

Each row has a favorite star on the left and a run/stop button on the right. Right-click a row for more actions: Show in File Browser, Open in Editor, Copy Path, Copy Relative Path, Copy Command, Run, Run in Background, Run with arguments…, Restart, Stop, and add/remove Favorite. Copy Command (scripts only) copies the exact command play would run, which the source-file path can’t convey when several targets share one file. Restart (available while running) interrupts the process and re-runs it in the same terminal. Run in Background runs the script without switching to its terminal (the same as Cmd-clicking Run on macOS, or Ctrl-clicking on Windows and Linux). Run with arguments… opens a terminal with the command typed but not yet run, so you can add arguments before pressing Enter.

You can also jump the other way: right-click a package.json, Makefile, CMakeLists.txt, project file, or executable in the File Browser and choose Show in Script Runner to reveal its entries in this list. The same jump is available when one of these files is open in the File view: click the Show in Script Runner icon in its header.

Type in the Filter box in the toolbar to narrow the list to matching names (favorited items always stay visible). Hover the info icon in the section header to see which folders the scan always skips: dependency and build-output directories (node_modules, packages, vendor, __pycache__, build, out, dist, target, CMakeFiles) and hidden folders. Skipping build output keeps the scan fast and its results clean on large projects, while your built executables still appear through the separate build-aware scan and the Recent sort.

The list has two layouts, selected with the View icon buttons in the toolbar. Tree is the default:

  • Tree shows the folder hierarchy the natural way to browse a project. Everything is anchored under a root node named for the project folder, so the hierarchy always has context. Folders are collapsible, a folder’s own items come before its subfolders, and each source file (package.json, CMakeLists.txt, and so on) is itself a collapsible node grouping the targets it defines, so you can see which file a build or configure target comes from. Programs are grouped under a Programs node. Source files start collapsed — open one to see its targets — so even a very large project opens compact rather than as a wall of entries (their targets aren’t built until you open the file).
  • List shows the items as a single-column vertical list under a heading for each source file, directory, or type (depending on the sort), with items indented beneath their heading. Click a heading to collapse or expand its group. Both layouts render only the rows currently on screen, so scrolling and resizing stay fast even on very large projects.

Alongside the View toggle, the toolbar has two more segmented controls. Sort (List only, disabled in Tree) orders the list by Path (filesystem-walk order, grouped by path), Name (one flat alphabetical list), Type (Scripts, then Programs), or Recent (programs newest-built first, scripts below). Show filters both layouts to All, Scripts, or Programs only, which is handy for zeroing in on your built executables without collapsing everything else. These controls wrap to a second line when the activity is too narrow to hold them on one row. To find a specific entry by name, type in the Filter box at the end of the toolbar.

Run scripts

To run a script, program, or command in Zide, click the Run icon. The script runs in a terminal and outputs the run results in the Outputs section.

Each script or program runs in its own terminal, which Zide reuses when you run the same entry again. By default the terminal comes to the front so you can watch the output; hold Cmd (macOS) or Ctrl (Windows and Linux) while clicking Run, or choose Run in Background from the right-click menu, to run without switching to it. While an entry is running, clicking the body of its pill jumps to its terminal.

When a run finishes, Zide asks the shell for the command’s exit code, which appears in the terminal as a short [zide] exit N line. That line is how success and failure are told apart (the status in History, the failure toast, and keeping failed terminals open); it is stripped from the saved run log.

Terminals stay open after a run finishes so you can read the output, and a terminal for a failed run always stays open. Two settings in Settings > Script Runner keep them from piling up:

  • Close terminal after a successful run (default 30 seconds; can be Never) closes a terminal that many seconds after its run finishes successfully. It won’t close a terminal you’re currently looking at — the wait defers while that terminal is on screen — and every run’s output is kept in History regardless.
  • Maximum idle Script Runner terminals (default No limit) is a hard ceiling: when a new run pushes the number of finished terminals past it, the oldest idle one is closed. Running and failed terminals are never closed by either setting.

A terminal that is running a Script Runner entry shows an attachment badge in its toolbar, presented like the entry’s pill: the filename over its folder. Click the badge body to jump to the matching entry in the Script Runner. The x disconnects the terminal from the entry (leaving the terminal open and running), so the Script Runner no longer tracks it.