Hacker News Reader

Comment by BeetleB | Hacker News Reader

Well, for one, your recipes can be in another language (e.g. Python).

You can build complex recipes out of simpler ones. Sure, you could do that by creating a new shell script that calls other shell scripts, but then you're reinventing just.

You don't need to be in the directory to run those scripts.

I think a better question for you: What's the benefit of putting .PHONY recipes in Makefiles, when you could just have a directory full of shell scripts. If you find yourself using .PHONY recipes, then you already have a reason to use just.

View on HN

> Well, for one, your recipes can be in another language (e.g. Python).

Surely this is true for stuff in a ./bin or ./scripts folder - binaries, python with shebang etc?

Ah, I see there's:

https://just.systems/man/en/shebang-recipes.html

Which could be done in shell, but typically rather be limited to oneliners (invoking awk) rather than piping a heredoc to an interpreter.

> You don't need to be in the directory to run those scripts.

There's already an easy way to solve this: $PATH.

> I think a better question for you: What's the benefit of putting .PHONY recipes in Makefiles, when you could just have a directory full of shell scripts. If you find yourself using .PHONY recipes, then you already have a reason to use just.

Well, I think it's the same question, rather than a better question. And the answer is yes, if all you need from make, now and in the future, is a set of .PHONY targets, then by all means just use shell scripts. make is used because often you need slightly more than this -- or you may do so tomorrow, and don't want to change the syntax you use to accomplish tasks.

> 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?

You can put `./scripts` in your $PATH, if you want.

Absolutely do not do this. That’s all well and good until you clone a repo that ‘scripts/ls’ => install_ransomwhere().

You could put `.$MY-SECRET` it `PATH` and selectively symlink this to vetted script directories

You can put .scripts last in PATH (or first - whichever disallows scripts/ls to take precedence over /usr/bin/ls)

1. 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.

Direnv is a great tool for this FWIW.

Won'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.

Are 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.

There's probably a tool that will work similarly in Windows. I was saying it merely because that's what the direnv Github page implies.

But won't all the scripts break?

Are 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.

I 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.

Although 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.

Reply on news.ycombinator.com