> Now I have i.e. `just check` in projects in different languages that all do the same thing -- check types and/or run various linters. I can go in a directory and run `just check` and I know I have taken care to have all checks that I want in place. Similarly I can run `just test` and I know I'll have the test suite ran, again regardless of the programming language or framework.

How is that different from having a scripts dir, and a script called `check` or `test`?

How is `just -l` different to `ls scripts`?

Tab completion. `just -l<tab>` shows all the commands and their descriptions.

Aside from that, it has lots of built-in ergonomics like consistent argument parsing, functions to say what OS you’re on, an easy way to hide helper functions, the ability to execute a justfile in a great-grandparent directory, etc.

You can totally do any of those things with shell scripts. I prefer letting someone else invent all the bells and whistles there so I don’t have to.

I am a bit confused. If you have your scripts in `scripts/`, doing `scripts/TAB` will also auto-complete! The other things seem like really minor benefits to me, not trying to say you should also feel the same, just giving my opinion.

Scripts/tab won’t show you the documentation of each script explaining what it’s for.

My genuine advice is to download it and play with it for an hour. If you don’t like it, you’ve learned a little about a tool you’re bound to come across sometime. If you do like it, now you’ve added another tool to your palette. Either way you learn something useful.

In my case I prefer all these utility scripts to be in one file because 90% of them are 1-2 lines anyway. Zero point dedicating a directory with several 5-line files.

I use "make", so I get most of this. But the one thing I would like is a sibling / parent / grandparent directory with ease, so I might switch.

I’ve used make for many things over the years. I’m competent with it. Make is such a breath of fresh air for the uses that don’t involve actually incrementally building software. It’s sooo less verbose. It’s hard to describe the feel of a thing, but imagine learning to program with Java and then finding Python. If you’re building a giant app developed by thousands of people, maybe Java’s complexity starts to show a benefit. If you just want to quickly script something up, Python gets the job done with a tenth the boilerplate.

There’s room for both. Neither replaces the other. But it turns out many of my projects need tools closer to Python/Just than Java/Make.

> Tab completion.

`./scripts/<tab>`

`./sc<tab><tab>`

I believe I already addressed that this is purely a matter of taste and convenience, not sure why you are not reading my comment and are asking for more.

And it was already said: if you like it more, use it. Nobody is holding a gun to your head. And I even explained that I used that in the past and moved away from it.

I also haven't seen in your previous response how Just is better than a subdir with shell scripts named according to a convention.

AFAICT, the productivity improvements you described came exclusively from using a consistent naming convention, not from Just. And since everyone's dev env supports subdirectories with shell scripts already, why not simply use that instead of requiring Just?

I got a down arrow on my comment that's your parent a minute before you responded. Coincidence, or you prefer to press it because you are not satisfied that I'm not your personal documentation agent?

Finally and additionally as a response: because it's also all in one place. I don't want 10+ scripts. For the third time: I used bespoke scripts and found them not good enough compared to Just, now for even more reasons clearly spelled out. Sigh.

I didn't downvote you, though I found your answer unhelpful. (I've now received 2 downvotes.)

10+ scripts with standard names ("clean", "test", "build", etc.) in a subdir added to $PATH seems to me to be easier to manage -- if the scripts are independent of each other. If they do have dependencies on each other, but the dependencies are "treelike" (meaning that for every target you might want to run, all of its transitive deps are reached via a unique path), it's still easier (than either make or Just) to have separate scripts, and turn each dep into a plain invocation at the top of each script. It's only when that approach starts to invoke deps multiple times (because it has become non-treelike) that either make or Just starts to offer an advantage.

I think if you look at this with clear eyes, you'll see that 100% of the value you feel you're getting from Just is actually coming from the naming convention that Just nudged you towards.

I like having individual files too as they can be independently managed by source control, linted, etc. And I've certainly been known to have a Makefile that's simply:

    all:
     @ls -1 tasks

    % :: tasks/%
     @./$<

And then fill my `tasks/` directory with individual executables.

Apologies for assuming you downvoted me then. :)

And I have not touched your comment btw. I rarely downvote these days and I have to be really pissed to do so. I was not pissed earlier, more like a little frustrated as you seemed to ask without reading, as if demanding a complete answer without willing to piece together the info given in several other comments.

So... you were talking about global scripts. I was not. I was talking about per-project directory with scripts because very often projects have their little quirks that make all their scripts frustratingly 99% identical but never 100%. I danced this tango dozens of times -- not exaggerating, I am a contractor (though I hope to finally stop, currently looking for a proper long-term job with good culture fit) and worked on many projects -- and ultimately got extremely frustrated.

At one point I did attempt to make those universal scripts you speak of. The even more maddening thing is that they worked for part of the projects... and didn't work for others. It was a rough 60/40 split. So you end up maintaining even more of them. So I gave up.

Very soon before that I found `just` and very quickly recognized the benefits: project-local commands / scripts, centralized location (just one file), ability to delegate to parent Justfile (i.e. you can have a dedicated folder for Golang projects and that one can contain a Justfile with e.g. `just lint` task that calls `go vet` and `staticcheck` etc., without having to copy-paste that into every Golang project Justfile file, though I actually prefer that nowadays -- better to have completely self-contained tooling after all but still, for super dev-specific stuff that does not belong in version control the parent Justfile workflow is quite a good fit), and a very easy syntax that still allows for doing stuff that will make you pull your hair out if you attempt them with pure sh or bash and if you haven't memorized their specifics over the course of a lifetime (which is something I attempted but gave up on because it was more or less memorization of exceptions of the exceptions).

Now, to address this:

> I also haven't seen in your previous response how Just is better than a subdir with shell scripts named according to a convention.

I am not impressed by conventions that are not enforced with a spiked club. Which means: we the people forget stuff easily. I suffered from that too. Conventions don't mean much when you misspell the script filename or put `-f` instead of `-e` in the `set` call at the top of the script. :)

I prefer loud failures and not silent mess-ups.

My position is informed by a lot of negative past experiences. Does not mean that my priorities are universal or unconditionally better. Not at all. It means that everything I got through in my career made me appreciate `just` and it was a near-perfect fit for my needs.

> I think if you look at this with clear eyes, you'll see that 100% of the value you feel you're getting from Just is actually coming from the naming convention that Just nudged you towards.

Sure, it encouraged me to finally settle on a naming convention but I've done this before as well. I still prefer the singular file approach + ability to delegate to parent files.

The less files in total the better. I have found this rule to make me more productive.

If you have gotten this far: nowhere did I claim objective improvements. I had discussions in the past (might have been in other `just` threads even!) with curmudgeons who loudly proclaimed "skill issue!" on my non-preference towards make's bash-isms and weird rules. So for them `make` + other scripts (even Perl / Python ones) are working just fine and the rest are "kids running after shiny toys".

I don't mind them thinking that. I have my motivation and, as said above, it's well-motivated given my past and my way of work and mental preferences.

Hope that helps.

Thanks for going into more depth. I wasn't aware that Just could delegate like that, which does sound useful. And I certainly agree that bash and make are absolutely Byzantine at this point -- footguns on footguns. There's much value in using a tool that is powerful enough to do what you need, but not much more -- since that makes it much easier to reason about what a given instance/invocation of that tool could possibly be doing, without spending hours (years?) down in the detail.

And it sounds like Just is that tool for you! I'll probably keep using make, now that I've spent so much time wrestling with its many idiosyncrasies, but you never know.

Thanks for productive response. <3

> And I certainly agree that bash and make are absolutely Byzantine at this point -- footguns on footguns.

Yeah, that's my problem. Not like I don't have memory in my brain, not like I can't learn make and bash -- I did so several times almost from scratch but as I am not using them every day, the memories always fade. It's best to relearn something without footguns than one with. Hence I am using `just`. It's straightforward and very easy to catch up with even if you forget it. Not so with make and bash.

If you are very invested in them and are feeling at home with them, great for you -- I am not claiming unquestionable and countless benefits. I am claiming it works well for my brain and my workflow, and most of all -- the frequency with which I have to do scripting.

I tried my best to get the discussion back on topic and off-topic low-effort replies like yours don't help.

Oh and I did not downvote him.

yep just has good ergonomics for little things in my dev workflow