Oleksandr Kozachuk
10a21d1f9d
Quick form now drives the one shared engine through commands only, so it and the console give identical results (form == console). - password hook answers only the "/" prompt, so read_master climbs and computes every ^parent from a single root master (Req 4) - new master in the field is authoritative via `unpass`; empty field reuses the stored session master, so later names generate without re-typing it (Req 1/2) - `unpass` with no name now clears ALL cached masters (real command, not a private hook) so the form stays reproducible in the console - result colour = root master marked correct (correct / / uncorrect /), derived live from the engine; black otherwise (Req 3) - Mark-correct toggle button; click the master to reveal it; honest memory-only hint - master stays in memory only, never written to storage; only the one-way correct hash is saved on the device parser: bare-name forms now keep a trailing comment, and a ^-led token is never a name, so `name ^parent` / `name MODE ^parent` link the parent instead of qpname reading it as prefix+name (was silently mis-stored).
Hel: password generator and manager
Hel is a password manager which newer stores the passwords but generates them according to the rules from the master password and the given name of the password.
Commands & behavior
ls <regex>matches case-insensitively (name, full line, and comment). Add an inline(?-i)to the pattern to force case-sensitive.source <file|command|>echoessource <target>so you see what was loaded.saveprints a diff against the previously loaded/saved snapshot before persisting:< line= removed,> line= added — so an accidental removal is visible on the save that would persist it. (Set-based, so dump ordering is irrelevant.) The baseline is seeded on startup load and refreshed on each save.
Persistence
Hel never stores secrets — only the entry catalog (names + generation rules),
which is a script of add … lines. That script can be saved to / loaded from a
file, an external command, or a Notion page.
set: configuration from ~/.helrc
Instead of environment variables, settings can live in the init script via
set <key> <value>:
set hel_dump |hel store notion:somenote
set hel_notion_token secret_xxxxxxxx
source hel load notion:somenote|
- Keys are case-insensitive. A
setis never written to the shell history, and its value is redacted in any echo (it may be a secret token). - Lookups check the
setmap first, then the matchingUPPERCASEenvironment variable. Soset hel_dump …overrides$HEL_DUMP, etc. - When hel runs a pipe/source command, the whole
setmap is exported (uppercased) into that child process — that is howset hel_notion_token …reaches a spawnedhel store/hel load.
Notion backend
The hel binary doubles as the Notion backend through two non-interactive
subcommands, designed to drop into the existing pipe plumbing:
hel store notion:<ref>— read the dump from stdin and write it into the Notion page (one code block, replaced in place).hel load notion:<ref>— fetch the page and print the dump to stdout.
<ref> is either a Notion page id (UUID) or a page title (resolved by search).
The integration token comes from HEL_NOTION_TOKEN (or set hel_notion_token …),
and the target page must be shared with that integration.
Wire it up so save pushes to Notion and startup pulls from it:
# ~/.helrc
set hel_notion_token secret_xxxxxxxx
set hel_dump |hel store notion:somenote
source hel load notion:somenote|
(Equivalently, export HEL_DUMP="|hel store notion:somenote" and
export HEL_NOTION_TOKEN=… in the shell.)