6 ms·

Couldn’t you do this with shell scripts? Make just runs commands anyway. If you’re not using make’s dependency-tracking features, might as well just use the she

Couldn’t you do this with shell scripts? Make just runs commands anyway. If you’re not using make’s dependency-tracking features, might as well just use the shell directly and use the simplest tool for the job.

xmprt 2y ago
make still has a better UI than shell scripts. With shell scripts you have to maintain multiple files whereas a Makefile has all the scripts in a single file.
- t3rra 2y ago
  wth. makefile can include other makefiles.
- edflsafoiewq 2y ago
  Why is that a better UI?
- SahAssar 2y ago
  No you don't. I like makefiles because of the dependencies between targets but for simple multi-target things I still do shell scripts like mything() { # ... } otherthing() { # ... } if [ $# -eq 0 ]; then echo "Usage: ./run.sh [mything, otherthing]" exit 1 fi "$@"
  - collinvandyck76 2y ago
    I've been writing scripts like this but with a case/esac at the bottom to map $1 to the right command. Have never thought about doing this instead. thank you for opening my eyes!
    - banish-m4 2y ago
      Been There, Done That, Bought The T-Shirt and leads to unmaintainable shit. One script per action. The end.
      - collinvandyck76 2y ago
        Maybe for your usecase, sure, but my usecase is my own dotfiles which has some of these helper scripts and it's a good fit there.
      - SahAssar 2y ago
        You express no nuance and only say that something is wrong without explaining why. Your communication skills lack "skill" and "communication". Your absolutism makes me convinced that you are are either wrong or incapable to explain why you would be right.
- banish-m4 2y ago
  That's a god function antipattern and rapidly becomes non-portable. Each lifecycle hook should be a an executable of some sort like "scripts/{{command}}", be it a shell script or something else.
cassianoleal 2y ago
I'm not GP but: Make gives me a single, predictable and stable interface to the repo. From the root of the repo, I can type `make <tab>` and get a list of available tasks. Alternatively, there's a Makefile on the root. With scripts, I need to type... what? `./<tab>` and look for clues? Maybe the scripts are in `scripts/`, maybe they're in `build/`, maybe they're in `ci/`... Even if I know where the scripts are, `make task` is quicker and easier to type than `./scripts/task.sh`. One could just use a make task to call a script, which I have done, but in most cases if you do that, what's the point of the script?
- chuckadams 2y ago
  > what's the point of the script? For starters, not having to indent every line with a tab, put backslashes at the end of each line, or double every $ sigil in the script. Being able to transparently replace it with perl or python or some other non-shell-script is an occasional bonus.
  - cassianoleal 2y ago
    You picked the least important point I made, stripped it out of context and argued against it. This is a strawman. Feel free to use it as a piñata, I don't care.
    - deleted 2y ago
      [deleted]
  - fuzztester 2y ago
    https://news.ycombinator.com/item?id=40350681 https://news.ycombinator.com/item?id=40350681

xmprt 2y ago

make still has a better UI than shell scripts. With shell scripts you have to maintain multiple files whereas a Makefile has all the scripts in a single file.

t3rra 2y ago
wth. makefile can include other makefiles.
edflsafoiewq 2y ago
Why is that a better UI?
SahAssar 2y ago
No you don't. I like makefiles because of the dependencies between targets but for simple multi-target things I still do shell scripts like mything() { # ... } otherthing() { # ... } if [ $# -eq 0 ]; then echo "Usage: ./run.sh [mything, otherthing]" exit 1 fi "$@"
- collinvandyck76 2y ago
  I've been writing scripts like this but with a case/esac at the bottom to map $1 to the right command. Have never thought about doing this instead. thank you for opening my eyes!
  - banish-m4 2y ago
    Been There, Done That, Bought The T-Shirt and leads to unmaintainable shit. One script per action. The end.
    - collinvandyck76 2y ago
      Maybe for your usecase, sure, but my usecase is my own dotfiles which has some of these helper scripts and it's a good fit there.
    - SahAssar 2y ago
      You express no nuance and only say that something is wrong without explaining why. Your communication skills lack "skill" and "communication". Your absolutism makes me convinced that you are are either wrong or incapable to explain why you would be right.
banish-m4 2y ago
That's a god function antipattern and rapidly becomes non-portable. Each lifecycle hook should be a an executable of some sort like "scripts/{{command}}", be it a shell script or something else.

cassianoleal 2y ago

I'm not GP but: Make gives me a single, predictable and stable interface to the repo. From the root of the repo, I can type `make <tab>` and get a list of available tasks. Alternatively, there's a Makefile on the root. With scripts, I need to type... what? `./<tab>` and look for clues? Maybe the scripts are in `scripts/`, maybe they're in `build/`, maybe they're in `ci/`... Even if I know where the scripts are, `make task` is quicker and easier to type than `./scripts/task.sh`. One could just use a make task to call a script, which I have done, but in most cases if you do that, what's the point of the script?

chuckadams 2y ago
> what's the point of the script? For starters, not having to indent every line with a tab, put backslashes at the end of each line, or double every $ sigil in the script. Being able to transparently replace it with perl or python or some other non-shell-script is an occasional bonus.
- cassianoleal 2y ago
  You picked the least important point I made, stripped it out of context and argued against it. This is a strawman. Feel free to use it as a piñata, I don't care.
  - deleted 2y ago
    [deleted]
- fuzztester 2y ago
  https://news.ycombinator.com/item?id=40350681 https://news.ycombinator.com/item?id=40350681