The following AI-generated aka vibe-coded software. The software is specific to my needs and my system and may not work for you or your system. Support is limited, but if you report a bug I'll certainly look into it. All code is provided in a zip file for you to review should you choose.

Scriptary

A Windows desktop library for your Python, PowerShell and batch scripts. Scriptary reads each script’s arguments and turns them into a form. It remembers the values you use and runs scripts in a built-in console with full colour and live progress output. It also records changes to your library so you can undo them, roll them back or restore a single script.

Contents

• Features at a glance
• Requirements
• Getting started
• Adding scripts
• How arguments are detected
• Organising the library
• Running scripts
• The output console
• Interpreters and execute fields
• Undo, redo and change history
• Chains: running scripts in order
• Schedules: runs at set times, and reminders
• Library reports
• Data files and safety
• Keyboard shortcuts
• Command line
• Troubleshooting

Features at a glance

• One library for .py, .ps1 and .bat scripts, with groups, virtual folders, labels, clones and notes.
• Automatic argument forms. Python arguments are read from argparse code, PowerShell arguments from the param() block, and batch arguments from %1–%9.
• Saved parameters per script, with an unsaved-changes indicator and a live preview of the exact command that will run.
• Built-in console using a real Windows pseudo-console (ConPTY) and a terminal emulator. Colours, progress bars and \r updates display correctly, and you can type input back to the script.
• Run as administrator for scripts that need elevation. Scripts that probably need it are detected and marked ⛨.
• Search and filters by name, description, path, GUI/no GUI, admin, last result and file type.
• Sorting by name, date registered or last run, within each group and folder or across the whole list.
• Chains: two or more scripts run one after another, stopping at the first that fails.
• Schedules: run a script automatically at set times while Scriptary is running, or be reminded to run it yourself.
• Keyboard shortcuts of your own: Ctrl+Shift (or Ctrl+Shift+Alt) and a letter, digit or F-key runs a script or a chain on its saved values, or opens a Manage window, a menu or clicks a button of the main window. Keys that another program or Windows has taken are refused.
• Undo, redo and a full change history. Undo one change, roll back to a point in time, or restore a single script’s settings and parameters.
• Archiving: retire a script you no longer use without losing its saved values, notes or run history. It leaves the list and search, and can be brought back at any time.
• Library reports under Manage: parameter names across the library, parameters with no help text, unused saved values, a run report, and archived scripts.
• Safe storage. Files are saved atomically, damaged files are detected and preserved, and a last-known-good copy of each data file is kept.
• Portable paths. Paths are stored against tokens such as %OneDrive% or %SCRIPTARY_HOME%, so a shared library works on several machines.
• System tray support and a single running instance.

Requirements

Install everything with:

python -m pip install pyte pystray pillow

If pyte is missing when Scriptary starts, it offers to install it for you.

Getting started

1. Put scriptary.pyw (and scriptary.ico, if you have it) in a folder of your choice.

2. Double-click scriptary.pyw, or run:

   pythonw scriptary.pyw

3. Click + Add to register a script, or 🔍 Scan to add every script in a folder tree. Both are in the button grid at the bottom of the sidebar.

4. Select a script, fill in its parameters, and click ▶ Run.

Only one copy of the GUI runs at a time. Starting it again brings the existing window to the front.

Choosing where data is stored

By default, Scriptary keeps its data files next to scriptary.pyw — or next to the executable, when it has been built into one. To keep them somewhere else, pass --config-dir:

pythonw scriptary.pyw --config-dir "C:\Scriptary\config"
pythonw scriptary.pyw --config-dir configs\myteam

A relative path is resolved from the folder containing scriptary.pyw (or the executable).

Restarting Scriptary

For picking up changes to Scriptary’s own code, start it with --show-self-restart-option TRUE:

pythonw scriptary.pyw --show-self-restart-option TRUE

Manage ▾ then ends with Restart Scriptary, and the tray menu has Restart above Exit. Scriptary closes and starts again with the same command line, --config-dir included, and reopens as it always does (same window, sort, collapsed sections and selected script; no output tabs). The option also accepts =TRUE, and 1, YES or ON in any case; anything else, or leaving it out, keeps the entry hidden.

Restarting, like exiting, asks first when parameter changes are unsaved or scripts are still running. Scripts running in output tabs are stopped. A script running as administrator in its own window keeps running, but its result is not recorded.

Adding scripts

When a registered file can’t be found, the script’s detail panel shows a red banner with a Locate file… button.

How arguments are detected

For a single Python script, Detect Arguments by Running Script… (right-click) runs the full detection once without turning the global option on. You are asked to confirm first, because any side effects of running the script will really happen.

Scriptary also looks for two other traits, shown next to the detection method and usable as filters:

• ⧉ graphical interface: the script opens a window, e.g. Tkinter or Qt in Python, or Windows Forms, WPF, Out-GridView or message boxes in PowerShell.
• ⛨ elevation: the script requires, checks for, or requests administrator rights.

Organising the library

• Groups: named collections created with + Group. Move scripts into them from the right-click menu (Move to → Groups).
• Folders: scripts are listed under the folder they live in on disk. You can also move a script into another folder, or into a new virtual folder that exists only in Scriptary. A virtual folder can be removed, which sends its scripts back to their own folders.
• Renaming a folder makes it a group: a folder section is named after a directory on disk, so it cannot be given a name of your own and stay a folder. Rename Folder as Group (right-click) turns any folder section — one from disk or a virtual one — into a group with the name you type, and moves its scripts into it.
  Nothing on disk is renamed or moved. Giving it the name of a group you already have merges the scripts into that group. Like other library changes, it can be undone.
• Labels: Rename Label changes the name shown in the list without renaming the file.
• Notes: ✎ Add note (on the detail panel or in the right-click menu) attaches free-text notes to a script.
  Notes appear under the title only for scripts that have one; long notes collapse with a Show all link.
• Archive: right-click a script → Archive to retire it. An archived script no longer appears in the list or in search results, but everything about it is kept, and the date it was archived is recorded. Manage ▾ → Archived Scripts… lists them, to unarchive or remove (see Archived scripts). A script that is a step of a chain can’t be archived; Scriptary names the chain so you can take it out first.
• Search: the search box filters by name, description or path. Press Ctrl+F to jump to it and Esc to clear it.
• FILTER ▾: in three groups. Show only: GUI / No GUI, Admin / No admin. Status: Failed / Succeeded on their last run, Due (a reminder is due), Idle 6+ months, Never run. File type: .bat, .ps*, .py*. Ticking several options narrows the list further. While filters or a search are active, a strip under the search box shows each filter as a chip (click one to remove it) and how many scripts are shown, e.g. 9 of 31.
• SORT ▾: sort by Name, Date registered or Last run, ascending or descending, either within each group and folder (the sections stay in alphabetical order) or across the whole list. Sorted across the whole list, the list is flat: there are no group or folder headers, and each row names its group or folder instead. Scripts never run come last whichever way the list is sorted by last run. The date column shows the date the list is sorted by. The button is highlighted while the sort is not the default (Name, A to Z, within each group and folder); Reset returns to it. When a run finishes, the list is re-sorted and the selected script stays where it is on screen.
• Date registered: when a script was added to the library, or cloned. Scripts added before Scriptary recorded this were given their file’s last modification date, once.
• ▾ / ▸ (right of the search box): collapse or expand every group and folder. Not available while the list is sorted across its whole length.
• Between sessions: Scriptary reopens with the same sort, the same groups and folders collapsed or expanded and the same script selected. The search box starts empty and no output tabs are open.
• Status dot: each script’s dot is green if its last run succeeded, red if it failed, and grey if it has never run.

Running scripts

The script header

Above the parameters, the selected script’s name is shown with a red ADMIN badge if it needs elevation. Under it is a line giving the script’s path, how its arguments were read and how many there are. ✎ Note, Clone and History on the right do the same as the matching right-click menu items.

The parameter panel

Each detected argument gets a row:

• Text fields for ordinary values; ON / OFF switches for flags; and for arguments with a fixed set of up to six choices, a row of those choices with the current one highlighted (longer lists use a drop-down).
• Required arguments are marked with a red *, and ⓘ shows the argument’s help text.
• Path arguments get three buttons: ⋯ browse, 📁 open the location in Explorer, and ↗ open the file with its associated application.
• Environment variables such as %USERPROFILE%\Documents are expanded when the script runs.
• Copying names: click or double-click a flag name to select it, or right-click it for options that copy the flag, the flag with its value, or every flag.

Panel actions:

Unsaved edits are kept when you switch between scripts. The ● Unsaved cell in the sidebar turns red and shows how many scripts have unsaved changes; clicking it jumps to the first one.
Scriptary warns you before discarding unsaved edits.

Command preview

The COMMAND box under the parameters shows the exact command that will be run, updated as you type, with the flags highlighted. A command too long for one line wraps, and the box grows to show it — up to six lines, after which it scrolls. Copy puts it on the clipboard.

Run as administrator

Elevated scripts run in their own console window after a UAC prompt, because Windows doesn’t let an elevated process’s output be captured in a non-elevated window. The exit code is still recorded in the library.
Run as administrator is also available from the right-click menu for any script.

If Scriptary itself is already running as administrator, ▶ Run is enough and the extra button is hidden.

The output console

Every run opens a new tab in the output area.

• Full terminal output: colours, cursor movement, progress bars and \r updates display as they would in a terminal (requires pyte).
• Input: type into the STDIN field at the bottom of a tab and press Send or Enter to answer prompts.
• ⏹ Stop ends the process. Copy output and Save output export the tab’s text.
• Close all closes every tab.
• Run state: each tab shows a green ■ while running, then a green ✓ or a red ✗. The tab’s footer shows the exit code and how long the run took, and the script’s status dot in the list is updated.
• pythonw.exe scripts: if the Python path points at pythonw.exe, the matching python.exe is used, since pythonw has no console to show output in.

The minimum console height can be set with the console_min_height key in the settings file.

Interpreters and execute fields

The Interpreters & execution strip at the top always shows which interpreters will run, e.g. python 3.12.4 · pwsh 7.4.5 · cmd /K /E:ON (versions are read in the background). Click it to open or close the settings below it; it starts closed on a new install. Every field remembers its history; the 🗑 button next to a field removes the current entry from that history.

Which PowerShell?

• pwsh.exe (PowerShell 7) is the current, actively developed version. Use it for new scripts, for scripts marked #Requires -Version 7, and when you want UTF-8 file handling by default.
• powershell.exe (Windows PowerShell 5.1) is built into Windows. Use it for scripts that depend on older Windows-only modules or commands such as Get-WmiObject.

The two versions have separate profiles, module folders and execution-policy settings, so a script can behave differently between them.

Note: with the PowerShell path left empty, every PowerShell run (normal, elevated and command-line) uses powershell.exe -NoProfile -ExecutionPolicy Bypass -File, i.e. Windows PowerShell 5.1. Set the path to pwsh.exe to use PowerShell 7 everywhere.

Undo, redo and change history

Scriptary records every meaningful change to the library, saved parameters and interpreter settings, and lets you reverse them.

Undo and redo

↶ Undo (Ctrl+Z) and ↷ Redo (Ctrl+Y), on the right of the Interpreters & execution strip, reverse and reapply library changes:

• refresh, scan, add, remove and clone;
• group and folder changes, and moving scripts between them;
• locating a moved file, and detecting arguments by running a script.

A confirmation lists what the change did and warns if the same scripts were changed again afterwards. Hovering over ↶ Undo shows what it would undo. When a removed script comes back, it is selected and scrolled into view, even inside a collapsed group or behind an active search.

In text fields, Ctrl+Z and Ctrl+Y keep their normal text undo and redo.

The History dialog

Open it with History in the top strip, or with History… in a script’s right-click menu to see only that script’s changes. The list shows every recorded change, newest first; undone changes are greyed out. The pane below shows exactly what changed, with old → new values.

What is and isn’t recorded

Recorded: – script entries, groups, folders, labels and notes; – saved parameters; – Python and PowerShell paths, command options, the argument-detection option, and the minimum console height.

Not recorded: – window size and position, pane sizes, collapsed groups, the list’s sort, and the selected script; – the text in the execute fields, and field histories; – last-run times and results.

To keep the history small and readable: – Saves that change nothing are skipped. – Repeated edits with the same label within two minutes are merged into one entry, and an edit that ends up back where it started disappears. – Only the previous values of what changed are stored, not copies of whole files. – Old entries are pruned after 60 days, or beyond 300 entries.

Chains: running scripts in order

A chain runs scripts one after another, each in its own output tab, stopping at the first that does not exit 0. It saves writing a wrapper script for “back up, then sync, then tidy”.

A chain is a thing of its own, with its own name and its own order — not an order stored on the scripts. A script can appear in several chains, or more than once in one, and where it is filed stays a separate question from what runs after it.

Building one

Manage ▾ → Chains…

Every change to a chain is recorded, so Undo reverses it like any other library change.

Running one

Chains ▾, next to Manage, lists your chains — click one to run it. Or press ▶ Run chain in the editor, or the chain’s keyboard shortcut if it has one (the menu shows it).

You can also build a chain without opening the editor: right-click a script → Add to chain, which lists your chains and the step the script would become, and offers New chain….

Each step opens its own tab, named 2/4 sync.ps1, and the tab is brought to the front as its step starts. At the top of each tab is a line saying where it sits in the chain and how the previous step ended. When a step fails, its tab says so and names the steps that were not run:

Chain 'Nightly' stopped: step 2 of 4 exited 3.
Not run: 3/4  tidy.py, 4/4  report.py

Stopping a step with ⏹ Stop counts as a failure and ends the chain.

What a chain will not do

A chain is checked before it starts, and will not start at all if any step cannot run — better to be told up front than to stop half way.

• Scripts that need administrator rights cannot be chained. An elevated script runs in a console of its own that Scriptary cannot read, and one that elevates itself reports the exit code of the copy that asked for elevation, not of the work. If Scriptary is itself running as administrator the question does not arise and such steps are allowed.
• A script whose file is missing, or one that has been removed from the library, blocks the chain until you fix or remove the step.

Two things worth knowing

• Steps run on their saved values. ▶ Run uses what is on screen, which belongs to the selected script; the other steps of a chain are not selected and have nothing on screen. A step with unsaved edits runs its saved values, and the editor says so in its Status column. Press Save first.
• Batch steps run with /C. A .bat normally runs inside a cmd.exe that is kept open for you to type into, which never ends — and so would never hand the chain its exit code. Chained batch steps exit instead, whatever Command options says.

Schedules: runs at set times, and reminders

A schedule attaches times to a script and does one of two things when a time comes round:

• Run it automatically. The script runs by itself, as if you had clicked ▶ Run, while Scriptary is running (hidden in the tray counts).
• Remind me to run it. The script is marked ⏰ in the list until you run it. Use this for jobs you want to watch, or ones that need you there.

A schedule belongs to one script entry. For a script with clones, each clone has its own schedules and runs on its own saved values.

Making one

Right-click a script → Schedule ▸:

Choose when it should happen:

The dialog shows the next few times as you type, so you can check it before saving.

Manage ▾ → Schedules… lists every schedule with what it does, when it next happens and how the last one went. From there you can add a schedule for the selected script, change one, turn it off and on, or remove it.

Adding, changing, turning off and removing a schedule are recorded in History, so Undo reverses them.

Automatic runs

A scheduled run differs from clicking ▶ Run in a few ways, all because nobody is at the panel when it starts:

• It runs on the saved values. What is on screen belongs to the selected script, so a scheduled run ignores unsaved edits. Press Save first.
• It opens in the background. The run gets a tab marked ⏱ (e.g. ⏱ backup.py), headed with its schedule. The tab you are looking at stays in front, and the status bar says the run started. When the schedule’s next run starts, it replaces the previous run’s tab if that run has finished.
• It is recorded like any other run. The status dot, Run History… and the Run Report all include it; Started from says Schedule. A failed run while the window is hidden in the tray shows a tray notification.
• Batch files run with /C, as chain steps do, so that they finish and return their exit code.
• Scripts that need administrator rights are not run, unless Scriptary itself is running as administrator. A UAC prompt would wait for someone to accept it. The time is noted as not run, with the reason.
• It doesn’t overlap itself. If the previous run from the same schedule is still going when the next is due, the new one is noted as not run.

Missed runs. If Scriptary wasn’t running at a scheduled time, or the computer was asleep, the schedule runs once when Scriptary is next running, however many times were missed. Untick If Scriptary was not running at the time, run it once when it next is to skip missed times instead.
Several runs due at once start a few seconds apart. A run counts as missed when it starts more than five minutes late.

Changing a schedule starts it afresh. Times before the change, or before a schedule was turned back on, never count as missed.

Reminders

• Where due reminders show:
  • A due reminder puts ⏰ after the script’s name in the list. Hover it to see since when and why.
  • A strip above the buttons at the bottom of the sidebar says how many scripts are due. Click it to list only those, and again to list everything. FILTER ▾ → Status → Due does the same.
• Clearing a reminder. Only a successful run (exit 0) clears it. That includes ▶ Run, running as administrator, a chain step, a scheduled run, or scriptary.pyw run (a command-line run counts once the window next reads the library: ⟳ Refresh or a restart).
  A run that fails leaves it due, and the reminder says the last attempt failed.
• When it comes back. After a successful run, the reminder returns at its next time. A “N days after its last successful run” reminder counts from that run. If the script has never succeeded, it counts from when you made the reminder.
• Putting one off. Right-click a due script → Reminder Due ▸ to Snooze it for 1 hour, 4 hours or until tomorrow, or to Skip This Time.
  A snooze applies to this occurrence only.

What is kept where

Schedules are stored in the library (COMPUTER_registry.json). What has happened to each schedule is stored in COMPUTER_settings.json and isn’t part of History: when it last ran, what it noted, snoozes and skips. Like everything else, schedules are per computer, so a shared configuration folder doesn’t run a script on every PC.

Library reports

Manage ▾, on the right of the Interpreters & execution strip, opens reports over the whole library. Each shows a count beside its name when there is something to look at.

Manage ▾ also opens the Chains and Schedules editors and the Keyboard Shortcuts list, with counts. The Schedules count includes how many reminders are due.

Each Manage window is open once at most: choosing it again, from the menu or with its keyboard shortcut, brings the open window to the front.

Select in Library, in the reports that offer it, opens every group and folder so the script is reached even if its section is collapsed. A search that narrows the script out of the list is the one thing that can hide it; the status bar says so.

Parameters without help

A parameter’s help text is read from the script itself — help= on a Python argument, a comment above a PowerShell parameter, a REM or :: comment above a batch token — and it is what the ⓘ beside the parameter shows. Anything without one leaves you guessing when you fill the form.

The report lists one row per undocumented parameter, with the script, the parameter, what the script is written in, and the folder the file is in. Select a row and click Select in Library (or double-click it) to jump to that script.

Write the help in the script, then use Refresh This Script from the right-click menu to read it again. Clones share their file’s parameters, so each file is listed once, and scripts whose file is missing are left out — their parameters are the last ones read and there is no file to edit.

Archived scripts

Right-click a script → Archive takes it out of the list and out of search results without forgetting it: its label, note, group, saved parameter values and run history all stay, and the date and time it was archived is recorded. Archived scripts are also left out of Parameter Names, Parameters Without Help and the Run Report, and out of the command line’s list.

A script that is a step of a chain can’t be archived — the chain would stop running with nothing in the list to explain why. Scriptary tells you which chains use it; remove it from them in Manage ▾ → Chains… first.

Manage ▾ → Archived Scripts… lists every archived script, newest first, with the date it was archived, what it is written in and its folder. Select one or more rows, then:

Both are recorded in the change history, so Undo reverses either. Adding a file that is only in the archive (+ Add) offers to unarchive it instead of adding it again.

Data files and safety

All files are prefixed with the computer name, so several PCs can share one config folder (for example, on OneDrive) without overwriting each other’s data.

How your data is protected

• Atomic saves. Each file is written to a temporary file and then swapped in, so a crash or full disk can’t leave a half-written file.
• Damaged files are never overwritten. If a data file can’t be read at start-up, it is preserved as .corrupt-DATE.json, and Scriptary offers to restore the last good copy, showing its date. If you decline, Scriptary starts with empty data, and the backup is kept under a dated name.
• Locked files aren’t mistaken for empty ones. If a file stays locked (by a sync client, for example), Scriptary reports an error, not treating the file as empty and saving over it.

Portable paths

Script paths are stored relative to the first matching location, with the longest match taking priority:

%SCRIPTARY_HOME% (the folder containing scriptary.pyw, or the executable it was built into), %OneDriveCommercial%, %OneDriveConsumer%, %OneDrive%, %LOCALAPPDATA%, %APPDATA%, %USERPROFILE%, %PUBLIC%, %ProgramData%, %ProgramFiles(x86)%, %ProgramFiles%, %SystemRoot%.

A library stored this way resolves correctly on any machine where the same folders exist.

Keyboard shortcuts

Manage ▾ → Keyboard Shortcuts… lists every shortcut:

1. yours;
2. Scriptary’s own, which can’t be changed;
3. every Ctrl+Shift and Ctrl+Shift+Alt combination that Windows or another program on this computer has taken, with what it does where that can be told. A global hotkey (such as a graphics driver’s overlay key) shows as Taken by another program, because Windows doesn’t say which program holds it.

Your own shortcuts

Give a script or a chain a shortcut, and pressing it runs that script or chain, whichever script is selected.

• Script: right-click it → Keyboard Shortcut…, or select it and click + Shortcut for selected script in the Keyboard Shortcuts list.
• Chain: Shortcut… in the Chains editor, or + Shortcut for a chain… in the Keyboard Shortcuts list.

In the dialog, press the keys you want. Each check is made as you press them, and the dialog says whether the keys can be used:

• Allowed keys: Ctrl+Shift or Ctrl+Shift+Alt with a letter, a digit or F1–F12, such as Ctrl+Shift+B, Ctrl+Shift+3, Ctrl+Shift+F5 or Ctrl+Shift+Alt+B. That is 96 combinations.
  • These never get in the way of typing.
  • Ctrl+Alt without Shift isn’t allowed because on many keyboards it is AltGr, which types characters such as @.
  • Use the left Alt key. The right Alt key is AltGr on many keyboards, and AltGr+Shift types characters on many layouts (Polish, Czech, Nordic, US-International and others). A press with the right Alt held is left to type, so a Ctrl+Shift+Alt shortcut only answers to the left Alt.
  • Scriptary’s own Ctrl+Shift+Z (redo in text fields) is refused, and so is Ctrl+Shift+Alt+F4, which Windows treats as Alt+F4 and closes the window.
• One key, one thing. Choosing a key another script, chain or action already has moves it, and the dialog says so before you save.
• Keys the rest of Windows has taken are refused.
  Windows gives such a key to its owner even while Scriptary is in front, so a Scriptary shortcut on it would never work. Scriptary checks three places:
  • a global hotkey another program has registered;
  • a Windows input-language hotkey (for example Ctrl+Shift+0 on some computers);
  • the shortcut key of a shortcut in the Start menu or on the desktop.

  Programs that watch the keyboard directly, such as keyboard remappers, can’t be detected and aren’t listed. If pressing a combination in the dialog shows nothing at all, such a program took the keys before Scriptary saw them.

Assigning, changing and removing a shortcut are recorded in History, so Undo reverses them. A clone doesn’t copy its original’s shortcut.

How a shortcut runs:

• Only in Scriptary’s main window. A shortcut works while the main window is in front, wherever the focus is in it, including a parameter field. It does nothing while the Chains editor, Schedules or any dialog is in front, and nothing when Scriptary is hidden or another program is in front.
• On saved values. Like a chain step, a script runs on its saved values, not on what is on screen. If the script has unsaved edits, the tab says they were not used. Press Save first.
• In a tab brought to the front, like ▶ Run. The tab starts with a line naming the shortcut. Started from in the Run Report says Keyboard shortcut.
• Not twice at once. Pressing it again while its last run is still going does nothing, and the status bar says why. Holding the keys down counts as one press.
• Administrator rights. A script that needs administrator rights runs elevated, as with ⛨ Admin, and asks you to accept the UAC prompt. A chain still can’t contain such a script.
• When it can’t run. A shortcut for an archived script, one whose file is missing, or a chain that can’t start says why in the status bar. The Keyboard Shortcuts list shows the same in its Status column.

If a shortcut’s keys are taken by another program later on, Scriptary notices when it starts and says so in the status bar. The Keyboard Shortcuts list checks again each time it opens.

Shortcuts are kept in the library (COMPUTER_registry.json), so, like schedules, they are per computer.

Shortcuts for Scriptary’s own windows, menus and buttons

+ Shortcut for an action… in the Keyboard Shortcuts list gives a key to one of these:

The key does just what the menu item or button does. ▶ Run runs the selected script on the values on screen, unlike a script’s own shortcut, which runs its saved values. Stop, Save output and Copy output act on the output tab in front. If the button is hidden or can’t be clicked at that moment, the key does nothing and the status bar says why.

− Remove, Clear and CLOSE ALL are left out on purpose: each is one stray key press from losing something.

A button’s tooltip and the Manage ▾ menu show the key. These shortcuts are preferences, kept in COMPUTER_settings.json; they aren’t recorded in History, so Undo doesn’t reverse them.

Scriptary’s own shortcuts

Command line

The same library can be used without the GUI. Use python.exe, not pythonw.exe, so that output appears in your terminal. --config-dir can be added to any of these commands.

python scriptary.pyw add <path\to\script>      Register a script
python scriptary.pyw list                      List scripts with their IDs (archived scripts are left out)
python scriptary.pyw run <script>              Run a script with its saved parameters
python scriptary.pyw remove <script>           Remove a script from the library
python scriptary.pyw --help                    Show usage

Naming a script

<script> can be any of the following, checked in this order:

1. its ID, or the first 6 or more characters of it, as shown by list;
2. its label;
3. its file name, with or without the extension (backup.py or backup).

Matching ignores letter case. If a name matches more than one script (for example, a script and its clones), nothing is run or removed.
Scriptary lists the matching scripts instead, so you can use a label or ID:

> python scriptary.pyw run backup
'backup' matches 2 scripts by file name. Use a label or ID instead:
   75c240ad  backup.py
   609317a2  Backup to NAS (backup.py)

> python scriptary.pyw run "backup to nas"

What run does

run behaves like the GUI’s ▶ Run button, but in your terminal:

• Parameters: it uses the values saved in the GUI for that script. Unsaved edits in an open GUI aren’t used.
• Interpreter: Python scripts use the Python path setting, or the Python running Scriptary if it’s empty.
  PowerShell scripts use the PowerShell path setting, or Windows PowerShell if it’s empty. Batch files run through cmd.exe.
• Working folder: PowerShell and batch scripts run from their own folder; Python scripts run from the current one.
• Output: the command is printed first (on stderr), then the script’s output and input use your terminal directly.
• Exit code: Scriptary exits with the script’s exit code, so run can be used in other scripts and scheduled tasks. The result also updates the script’s status dot in the GUI.
• Administrator rights: if the script needs them and the terminal isn’t elevated, a warning is printed. Run the terminal as administrator in that case.

Exit codes from Scriptary itself: 1 means the script or its file wasn’t found, or a data file is damaged; 2 means the name matched more than one script.

Other notes

• add and remove are recorded in the change history, so they can be undone from the GUI.
• If a data file is damaged, the commands stop without changing anything and ask you to open the GUI, which offers to restore the last good copy.

Troubleshooting

Output has no colours or progress bars. Scripts only run on a pseudo-console when pyte is installed and this Windows provides one (10/1809 and later); otherwise output comes through plain pipes. Install pyte and restart Scriptary.

Scripts take a few seconds to start. Scriptary uses the pseudo-console built into Windows. If that is unavailable it falls back to pywinpty, which ships its own console (conpty.dll and OpenConsole.exe) that on some machines takes about three seconds to start, whatever the command. In that case Scriptary measures both of pywinpty’s backends once and uses the faster, and the status bar says when it switches. To decide for yourself, set pty_backend in the settings file to system, conpty or winpty.

A PowerShell script is blocked by the execution policy. Each PowerShell version has its own execution policy.
Check it with Get-ExecutionPolicy -List in the same version your PowerShell path points at. Alternatively, add -ExecutionPolicy Bypass to the PowerShell path.

Accented or non-English characters are garbled in a PowerShell script. Windows PowerShell 5.1 reads a script without a byte-order mark using the system’s legacy code page. Save the script as UTF-8 with BOM, or run it with pwsh.exe.

run says a name matches several scripts. Use list to see the IDs, then run the script by its label or ID.

“Scriptary could not read its … file” at start-up. A data file was damaged, for example by an interrupted sync. Choose Yes to restore the last good copy. The damaged file is kept beside it as .corrupt-DATE.json if you need to recover anything from it by hand.

I undid something by mistake. Press Ctrl+Y, or open History, select the Undo: entry and click Redo.

A script’s arguments look wrong. Right-click it and choose Refresh This Script. For Python scripts that build their parsers dynamically, use Detect Arguments by Running Script….