5 ms·

Why use this over .sh files?

by Traubenfuchs 2y ago

petesergeant 2y ago
Why use .sh files over this?
- al_borland 2y ago
  Fewer tools to manage. It seems like this could also be replaced by some aliases in a .bashrc file. I don't like adding extra dependencies and complicating things if they aren't adding significant benefit. What am I missing here? It seems like an alias with extra steps.
- xigoi 2y ago
  Because they don’t require installing a new tool and learning new syntax.
- homebrewer 2y ago
  When this tool becomes as available out of the box as POSIX sh (i.e. practically everywhere, including embedded systems and containers), then this reversed argument will make some sense. I'm willing to bet anything that POSIX sh will still be with us 50+ years from now, and 'just' will be long forgotten by then. You really should have a stronger argument for introducing another dependency into your build process (and onto your developers) than "it has a slightly simpler syntax compared to the industry standard".
  - bigstrat2003 2y ago
    It's not "slightly simpler", it's massively simpler. Shell scripts are pretty much the worst syntax in existence (barring esolangs that go out of their way to be weird).
    - Hackbraten 2y ago
      While shell syntax may be quirky, it absolutely allows you to write scripts that are simple, easy to understand, and maintainable.
  - BeetleB 2y ago
    It's great that POSIX sh is available everywhere except where it isn't (Windows). In all SW teams I've been in except one, sh was available, and people preferred writing things in something else (usually Python/Perl). I have had an order of magnitude more success convincing teammates to use just than convincing them to use sh. It may be ubiquitous, but it's useless if you can't convince non-shell gurus to use it.
Fluorescence 2y ago
IMHO you'd right to be sceptical because for me, it is only a slightly more ergonomic way to organise and run shell scripts. It's difficult to make the case it's much better but I found it interesting how "just being a bit nicer" for a common activity can be a really valuable quality of life improvement. - easier - core benefit is making it nicer to implement multiple commands with arguments without inventing something equivalent in shell - convenient - with "fallback" just will search up the folder tree to find the just command so I don't need to be in the right folder. I have justfiles at multiple levels in a project hierarchy and my cwd works as context to pick the right command - polyglot - can use different languages as needed - predictable - it's so nice when I return to a project and I have recipes for setting up my env, various types of build and test. The consequence of being a little more ergonomic means I capture more useful command lines that, for whatever reason, I would not have made into shell scripts because of the added friction.
- e12e 2y ago
  > with "fallback" just will search up the folder tree to find the just command So don't have just-files in your home directory?
  - Fluorescence 2y ago
    You could if you want. If you don't want just to search outside of your project folder then don't set fallback in your project root justfile and it stops there.
IshKebab 2y ago
I don't know if this fixes the issues but some big problems with shell: * Very bad UX on Windows * Quoting is a disaster. I mean, the whole language is a disaster but quoting is an especially big wart. Make also has this issue; you literally can't use it with files containing things like spaces or colons. * Shell scripts tend to start simple and reasonable and grow seamlessly into something that absolutely should not be a shell script. My favourite solution is Deno. Zero faff to set up, easy to install, supports third party dependencies without metadata files or messing with environments, and you get to use a real programming language. Easily the best scripting tool for infrastructure tasks at the moment. Unfortunately I'm forced to use Python at work which is nowhere near as good as Deno, but still beats the pants off shell scripting.
- Hackbraten 2y ago
  > Quoting is a disaster. It surprises me a bit that, of all things that are a mess in shell, your comment mentions quoting. It’s one of the few things that absolutely make sense for me in shell scripting. Do you have an example for me where quoting feels messy to you? > My favourite solution is Deno. Easily the best scripting tool for infrastructure tasks at the moment. I don’t think there’s an objectively best technology for everyone. For example, how long-term are your infrastructure tasks? What are the chances your scripts are still going to work in 2 years? 5 years? 10 years? Suppose you’re in a large enterprise embedded project which needs to work for 10 years or more, and the project uses shell scripts for infra tasks. Would you recommend to migrate those to Deno or Python?
  - IshKebab 2y ago
    Yes, this was literally from today: https://programming.dev/post/22539101 https://programming.dev/post/22539101 Turn on shellcheck and you'll realise that nobody could get it right without tool assistance. In programming languages with "standard" quoting (Python, JavaScript, Rust, Go, C, etc.) you don't even really need to think about it. > What are the chances your scripts are still going to work in 2 years? 5 years? 10 years? 100% because I'll maintain them. > Suppose you’re in a large enterprise embedded project which needs to work for 10 years or more, and the project uses shell scripts for infra tasks. Would you recommend to migrate those to Deno or Python? Absolutely yes. In fact the longer you expect it to last the stronger my recommendation would be. A shell script with 10 years of tech debt is a scary prospect.
bigstrat2003 2y ago
Because shell is absolutely miserable to work with, whereas Just has decent syntax.
- olejorgenb 2y ago
  I know the OP said ".sh files", but you can have executable python files (for instance as well)

Why use this over .sh files?

petesergeant 2y ago

Why use .sh files over this?

al_borland 2y ago
Fewer tools to manage. It seems like this could also be replaced by some aliases in a .bashrc file. I don't like adding extra dependencies and complicating things if they aren't adding significant benefit. What am I missing here? It seems like an alias with extra steps.
xigoi 2y ago
Because they don’t require installing a new tool and learning new syntax.
homebrewer 2y ago
When this tool becomes as available out of the box as POSIX sh (i.e. practically everywhere, including embedded systems and containers), then this reversed argument will make some sense. I'm willing to bet anything that POSIX sh will still be with us 50+ years from now, and 'just' will be long forgotten by then. You really should have a stronger argument for introducing another dependency into your build process (and onto your developers) than "it has a slightly simpler syntax compared to the industry standard".
- bigstrat2003 2y ago
  It's not "slightly simpler", it's massively simpler. Shell scripts are pretty much the worst syntax in existence (barring esolangs that go out of their way to be weird).
  - Hackbraten 2y ago
    While shell syntax may be quirky, it absolutely allows you to write scripts that are simple, easy to understand, and maintainable.
- BeetleB 2y ago
  It's great that POSIX sh is available everywhere except where it isn't (Windows). In all SW teams I've been in except one, sh was available, and people preferred writing things in something else (usually Python/Perl). I have had an order of magnitude more success convincing teammates to use just than convincing them to use sh. It may be ubiquitous, but it's useless if you can't convince non-shell gurus to use it.

Fluorescence 2y ago

IMHO you'd right to be sceptical because for me, it is only a slightly more ergonomic way to organise and run shell scripts. It's difficult to make the case it's much better but I found it interesting how "just being a bit nicer" for a common activity can be a really valuable quality of life improvement. - easier - core benefit is making it nicer to implement multiple commands with arguments without inventing something equivalent in shell - convenient - with "fallback" just will search up the folder tree to find the just command so I don't need to be in the right folder. I have justfiles at multiple levels in a project hierarchy and my cwd works as context to pick the right command - polyglot - can use different languages as needed - predictable - it's so nice when I return to a project and I have recipes for setting up my env, various types of build and test. The consequence of being a little more ergonomic means I capture more useful command lines that, for whatever reason, I would not have made into shell scripts because of the added friction.

e12e 2y ago
> with "fallback" just will search up the folder tree to find the just command So don't have just-files in your home directory?
- Fluorescence 2y ago
  You could if you want. If you don't want just to search outside of your project folder then don't set fallback in your project root justfile and it stops there.

IshKebab 2y ago

I don't know if this fixes the issues but some big problems with shell: * Very bad UX on Windows * Quoting is a disaster. I mean, the whole language is a disaster but quoting is an especially big wart. Make also has this issue; you literally can't use it with files containing things like spaces or colons. * Shell scripts tend to start simple and reasonable and grow seamlessly into something that absolutely should not be a shell script. My favourite solution is Deno. Zero faff to set up, easy to install, supports third party dependencies without metadata files or messing with environments, and you get to use a real programming language. Easily the best scripting tool for infrastructure tasks at the moment. Unfortunately I'm forced to use Python at work which is nowhere near as good as Deno, but still beats the pants off shell scripting.

Hackbraten 2y ago
> Quoting is a disaster. It surprises me a bit that, of all things that are a mess in shell, your comment mentions quoting. It’s one of the few things that absolutely make sense for me in shell scripting. Do you have an example for me where quoting feels messy to you? > My favourite solution is Deno. Easily the best scripting tool for infrastructure tasks at the moment. I don’t think there’s an objectively best technology for everyone. For example, how long-term are your infrastructure tasks? What are the chances your scripts are still going to work in 2 years? 5 years? 10 years? Suppose you’re in a large enterprise embedded project which needs to work for 10 years or more, and the project uses shell scripts for infra tasks. Would you recommend to migrate those to Deno or Python?
- IshKebab 2y ago
  Yes, this was literally from today: https://programming.dev/post/22539101 https://programming.dev/post/22539101 Turn on shellcheck and you'll realise that nobody could get it right without tool assistance. In programming languages with "standard" quoting (Python, JavaScript, Rust, Go, C, etc.) you don't even really need to think about it. > What are the chances your scripts are still going to work in 2 years? 5 years? 10 years? 100% because I'll maintain them. > Suppose you’re in a large enterprise embedded project which needs to work for 10 years or more, and the project uses shell scripts for infra tasks. Would you recommend to migrate those to Deno or Python? Absolutely yes. In fact the longer you expect it to last the stronger my recommendation would be. A shell script with 10 years of tech debt is a scary prospect.

bigstrat2003 2y ago

Because shell is absolutely miserable to work with, whereas Just has decent syntax.

olejorgenb 2y ago
I know the OP said ".sh files", but you can have executable python files (for instance as well)