@runfile/cli 1.9.0 → 1.9.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +25 -6
- package/bin/darwin-arm64/run +0 -0
- package/bin/darwin-x64/run +0 -0
- package/bin/linux-arm64/run +0 -0
- package/bin/linux-x64/run +0 -0
- package/bin/win32-arm64/run.exe +0 -0
- package/bin/win32-x64/run.exe +0 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -628,6 +628,10 @@ A list becomes one argument per item, so give it a word of its own rather than g
|
|
|
628
628
|
`{{ files }} suffix`, not `{{ files }}suffix`. An empty list is no words at all, so `rm -rf {{ dirs }}/cache`
|
|
629
629
|
with an empty `dirs` is `rm -rf /cache`; `run :lint` flags that glued shape.
|
|
630
630
|
|
|
631
|
+
An `exec` line is read by no shell: the runner splits it into the program and its arguments itself, and writes
|
|
632
|
+
each value for that, so a value there arrives the same way — one argument, or one per item of a list, quotes
|
|
633
|
+
and all.
|
|
634
|
+
|
|
631
635
|
### Asking whether a command worked
|
|
632
636
|
|
|
633
637
|
A `$` run may stand as a condition or as a `match` subject. The condition is true when the command exits 0;
|
|
@@ -809,7 +813,7 @@ Set at the top of the file, or inside a block where marked.
|
|
|
809
813
|
| --- | --- | :-: | :-: |
|
|
810
814
|
| `.shell` | Which POSIX shell `$` lines use. | | |
|
|
811
815
|
| `.env.NAME` | Set an environment variable. | ✅ | |
|
|
812
|
-
| `.workdir` | Where commands run. | ✅ | |
|
|
816
|
+
| `.workdir` | Where commands run, and what every relative path below it resolves against. | ✅ | |
|
|
813
817
|
| `.ignore-errors` | Keep going when a command fails. | ✅ | ✅ |
|
|
814
818
|
| `.logging` | Announce each command on stderr before it runs. Off unless set. | | ✅ |
|
|
815
819
|
| `.env-file` | Load a `.env` file (encrypted values are decrypted in memory). Appends. | ✅ | |
|
|
@@ -995,15 +999,23 @@ separated the way `PATH` separates them, or `*` for all.
|
|
|
995
999
|
`$HOME/.runfiles/` holds machine-wide targets, available in every project. If you would rather see the
|
|
996
1000
|
directory than hide it, `$HOME/runfiles/` and `$HOME/Runfiles/` are read too — but only one of the three may
|
|
997
1001
|
hold anything. `run :list` puts them first, under `global:`: they are the part of the listing you cannot see
|
|
998
|
-
by looking at the project.
|
|
1002
|
+
by looking at the project. That holds for `~/runfiles` too, though it sits where the walk up from anywhere in
|
|
1003
|
+
your home directory looks: it is never taken for a project, so from a directory with no `runfiles/` of its
|
|
1004
|
+
own you get your global targets — and not every project under your home as a subproject.
|
|
1005
|
+
|
|
1006
|
+
A machine-wide target's `runfiles/` parent is your home directory, so that is where its commands run. One that
|
|
1007
|
+
acts on the project in front of you says so with `.workdir = RUN.cwd` — and every relative path follows it, so
|
|
1008
|
+
`read_file("package.json")` and `.env-file = ".env"` read the project's files, not your home's. A `_shared.run`
|
|
1009
|
+
in the machine-wide directory can say it once for all of them.
|
|
999
1010
|
|
|
1000
|
-
A machine-wide target can say where it belongs, so one directory can hold work for several places at once:
|
|
1011
|
+
A machine-wide target can also say where it belongs, so one directory can hold work for several places at once:
|
|
1001
1012
|
|
|
1002
1013
|
```sh
|
|
1003
1014
|
# ~/.runfiles/deploy.run
|
|
1004
1015
|
# Ship the current branch
|
|
1005
1016
|
|
|
1006
1017
|
.only-in-directories = ["~/work/acme", "~/work/zed"]
|
|
1018
|
+
.workdir = RUN.cwd
|
|
1007
1019
|
|
|
1008
1020
|
$ ./scripts/ship
|
|
1009
1021
|
```
|
|
@@ -1021,9 +1033,16 @@ project's lint leaves the directory out otherwise.
|
|
|
1021
1033
|
**Not in CI.** A runner's home directory is nobody's, so `run` reads none of the three there: what runs is
|
|
1022
1034
|
what is checked in and reviewable. This is also why nothing has to be cleaned up after a job.
|
|
1023
1035
|
|
|
1024
|
-
Everything relative —
|
|
1025
|
-
— resolves against **the
|
|
1026
|
-
|
|
1036
|
+
Everything relative — a command, `glob`, `read_file` and the other file functions, `.env-file`, `.add-path`,
|
|
1037
|
+
`.watch`, and `.workdir` itself — resolves against **the working directory in effect where it is written**. One
|
|
1038
|
+
rule, so a path names the same file to the language as it does to the shell on the next line. The working
|
|
1039
|
+
directory starts at the parent of `runfiles/`, which is `{{ RUN.parent }}`, and a `.workdir` moves it from its
|
|
1040
|
+
own line down to the end of its block. A nested one is relative to the one around it, the way `cd` is:
|
|
1041
|
+
`.workdir = "src"` inside a block under `.workdir = "web"` is `web/src`. A path written *above* a `.workdir`
|
|
1042
|
+
keeps the directory it was written in, so `.add-path = "web/node_modules/.bin"` above `.workdir = "web"` still
|
|
1043
|
+
names the subproject's tools. An absolute path is taken as written, and an absolute `glob` pattern answers with
|
|
1044
|
+
absolute paths. `RUN.parent` and `RUN.cwd` never move: the first is the project, the second is where you typed
|
|
1045
|
+
`run`.
|
|
1027
1046
|
|
|
1028
1047
|
## Setup targets
|
|
1029
1048
|
|
package/bin/darwin-arm64/run
CHANGED
|
Binary file
|
package/bin/darwin-x64/run
CHANGED
|
Binary file
|
package/bin/linux-arm64/run
CHANGED
|
Binary file
|
package/bin/linux-x64/run
CHANGED
|
Binary file
|
package/bin/win32-arm64/run.exe
CHANGED
|
Binary file
|
package/bin/win32-x64/run.exe
CHANGED
|
Binary file
|
package/package.json
CHANGED