@plurnk/plurnk-execs-common 0.2.9 → 0.2.10

package/README.md

@@ -21,6 +21,15 @@ The manifest claims the subprocess runtime tags. The framework's `probe()` (per-
 | `bc` 🧮 | bc | stdin (e.g. `6 * 7`) |
 | `awk` 🪄 | awk | program arg, empty stdin (`BEGIN { … }`) |
 
+### A program with stdin — the `(target)` slot
+
+The table above is the **inline** form: `command` is the program. Put a program in the **`(target)` slot** instead and `command` becomes its **stdin** — a shell runs `sh -c "<target>"` (the shell tokenizes it; we don't), any other interpreter runs `<interpreter> <target>` (a script file). Same two slots, each mapped to its tool's CLI (plurnk-execs#15):
+
+```
+<<EXEC[sh](./deploy.sh --prod):yes\nyes\nno:EXEC     # run a script, prompts answered on stdin
+<<EXEC[python](transform.py):3\n1\n4\n1\n5:EXEC       # feed a python script its stdin
+```
+
 All run arbitrary code → `effect: host` → **proposal-gated** (not auto-run). For the snappy auto-run tier, see the pure in-process evaluators (`calc`/`jq`/`wasm`, planned). Input-processing transforms (`sed`, input-driven `awk`) await the EXEC input-channel and aren't claimed here.
 
 ## Configuration

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@plurnk/plurnk-execs-common",
-    "version": "0.2.9",
+    "version": "0.2.10",
     "description": "Universal subprocess executor for plurnk-service's exec scheme — one package exposing the shell + node + python floor plus whichever host interpreters (perl, ruby, php, lua, awk, bc, …) are present.",
     "keywords": [
         "plurnk",