3 ms·
> There's already an easy way to solve this: $PATH. I have 10 projects. Each with their own set of shell scripts. You want me (and all other developers) to pol
by BeetleB 2y ago
> There's already an easy way to solve this: $PATH.
I have 10 projects. Each with their own set of shell scripts. You want me (and all other developers) to pollute the $PATH with 10 directories?
And then you have a namespace problem. I usually have a "test" recipe in my justfiles. The analog would be a test.sh file. But with your solution, it will have to be projA-test.sh and projB-test.sh.
And if I dump them all into the $PATH, how do I quickly see the scripts relevant to a particular project?
- L3viathan 2y agoYou can put `./scripts` in your $PATH, if you want.
- kstrauser 2y agoAbsolutely do not do this. That’s all well and good until you clone a repo that ‘scripts/ls’ => install_ransomwhere().
- olejorgenb 2y agoYou could put `.$MY-SECRET` it `PATH` and selectively symlink this to vetted script directories
- olejorgenb 2y agoYou can put .scripts last in PATH (or first - whichever disallows scripts/ls to take precedence over /usr/bin/ls)
- BeetleB 2y ago1. This requires that all your projects use "scripts" as the directory name. 2. This works only if you just happen to be in the directory above scripts.
- nerdponx 2y agoDirenv is a great tool for this FWIW.
- BeetleB 2y agoWon't work in Windows. I think it really has to be emphasized: One of the great things about just is that it works in Windows with no hassles.
- akoboldfrying 2y agoAre you sure it won't work? I ask because cmd.exe has DOSKEY, which is basically a very slightly souped up version of bash's alias. I think it wouldn't be hard to use DOSKEY to replace CD and PUSHD with macros that run some command to update %PATH% and then change directory as usual.
- BeetleB 2y agoThere's probably a tool that will work similarly in Windows. I was saying it merely because that's what the direnv Github page implies.
- nerdponx 2y agoBut won't all the scripts break?
- BeetleB 2y agoAre you writing scripts that will break? just isn't something magical that will make scripts meant for Linux work in Windows, you know. Some people do actual development in Windows and have Windows scripts.
- akoboldfrying 2y agoI tend to work on different projects in different terminal sessions so I don't find this a problem, but OK, I can see the benefit of making the tasks a command line executes dependent on the current directory. (There are tools that can auto-adjust $PATH for you like this, but that would be a weak argument against Just (unless you're using them already) since it would mean swapping Just for that-other-tool.) If you use git and don't need multiple "layers" of Justfiles (i.e., if you have all your scripts in a scripts folder at the top level of your repo), then in bash you can get what you want with: run(){ `git rev-parse --show-toplevel`/scripts/$*; } Now from any repo subdir, `run clean` will run a script named "clean" in the scripts folder at the top level.
- BeetleB 2y agoAlthough I'm coming off as a strong just evangelist, I do want to point out that if someone already has a workflow with just scripts, it's totally OK to continue with that. Personally, I think using just is simpler for those who already don't have that workflow. Likewise, if you are using make as a command runner and already know make well enough - by all means continue! In my experience, though, someone who doesn't know make will be much more likely to learn just than make. I tend to sneak justfiles into the projects I work on. They usually don't have any good automation (no make, perhaps some scripts with a doc/md file explaining which script is for what). I sneak the justfile in the repository, and when it's mature, start showing teammates how I use it. They typically then switch to it. I don't think they would switch to it if it were a Makefile.