rios0rios0 / rios0rios0/dev-toolkit
Analyze remaining shell functions for potential migration to devforge
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 5
- Forks
- 0
- Avg merge
- 3h 3m
- Merged PRs (30d)
- 38
Description
Context
During the shell-to-devforge migration (dotfiles PR #75), several shell functions were successfully ported:
git-sync-repos→dev repo syncdip/dreset→dev docker ips/dev docker reset_vm_use_go/_vm_use_node/_vm_use_python→dev project use
However, two groups of functions were left behind. This issue tracks analyzing whether and how they could be migrated.
Keep in Shell (cannot migrate today)
These were skipped because they mutate the parent shell environment (env vars, cd) or are trivial one-liners. The core blocker is that a subprocess cannot export variables or change the working directory of the parent shell — but the same eval "$(dev ...)" pattern used for dev project use could potentially be applied here.
| Function | What it does | Blocker |
|---|---|---|
aws-prof() |
Sets AWS_PROFILE env var |
Subprocess can't export to parent shell |
azm-subs() |
Wraps az account set --subscription |
Trivial one-liner |
reload-credentials() / _op_load_references() |
Loads secrets from 1Password into env vars | Subprocess can't export to parent shell |
| Kubernetes kubeconfig merging | Auto-detects and sets KUBECONFIG from ~/.kube/config-files/ |
Subprocess can't export to parent shell |
pyenv() wrapper / _vm_cleanup_pyenv_locks() |
Handles noclobber and stale lock file issues | Shell-level workaround for pyenv bugs |
ls/ll/la/lt/t eza aliases |
Modern file listing with eza | Personal shell preferences |
Questions to investigate
- Could
aws-prof,reload-credentials, and kubeconfig merging use theevalpattern (printexportstatements to stdout)? - Is there value in centralizing 1Password credential loading into devforge, or does it belong in dotfiles?
- Should the pyenv workarounds be upstreamed to pyenv itself rather than maintained in either devforge or dotfiles?
- Are eza aliases worth managing in a CLI tool, or are they purely shell configuration?
Out of Scope (not development-related)
These are utility functions unrelated to software development workflows. They likely don't belong in devforge but are listed here for completeness.
| Function | What it does |
|---|---|
clear-h() |
Clears shell history files |
clear-logs() |
Clears system log files older than 5 days |
pdf-join() |
Joins two PDFs with pdftk |
pdf-to-jpg() |
Converts PDF to JPG with ImageMagick |
jpg-to-pdf() |
Converts JPGs to PDF with ImageMagick |
video-to-mp4() |
Converts video to MP4 with ffmpeg |
References
- Dotfiles repo: rios0rios0/dotfiles
- Migration PR: dotfiles#75
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing dotfiles PR #75 and the shell functions listed in this issue, then compare them with the existing devforge commands. Document a decision for each in-scope group: migrate it, keep it in dotfiles, or investigate upstream ownership, including whether the eval pattern is appropriate. Done means the migration scope and next steps are agreed without including the out-of-scope utilities.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, shell
- Domain
- cli, developer-experience
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100