I have a small fish function that does something similar. It saves output to a file in XDG_CACHE_HOME. I wouldn’t use it for sensitive items like passwords or tokens in the examples, but I do use it for scripts that need to fetch some data from the network.
replyFor example, I have a script for automating the creation of PRs which fetches the available labels for a repo from github and presents them with fzf multi select. I store the labels with a TTL of a week so that I don’t have to fetch them every time and the script compares the file’s age against the desired TTL to invalidate.
I find it useful for augmenting other programs, but I’m not typically using it on the cli directly.
From the example in the Readme, I guess retrieving a token from an API, using a secret fetched from a secure vault that requests a password or TouchID validation.
replyNot sure if there could be other interesting uses. I can’t think of one anyways.
Yes, exactly. This is especially frustrating when I leave an agent running for a long time and it gets stuck on my build scripts because it's waiting for my approval.
replyI just want to avoid leaving my credentials and secrets on the filesystem.
EDIT: I use a lot of direnv / mise. So reloading credentials with different values is common.
I have the same question, especially since any CLI output can be stored explicitly in some variable or temp file. What's the advantage of storing the output implicitly?
replyI don't want to store them in a file since I don't trust my agents with that data. Instead, the daemon secures the values using/under an HMAC key, making them virtually impossible to guess.
replyI might use this when i make massive `kubectl get -o json` calls to store the output so i can noodle with some jq i'm using to filter it. Right now it looks like OUTPUT=$(kubectl... -o json); echo $OUTPUT | jq '.blahblahblah' .. this seems like it might be more useful and if i'm working so long my ttl expires it will refetch say every 2m.. if i'm reading this properly.
reply