3 ms·

Shell scripts are a more evolved form of programming and nobody can change my mind on that. They require less work, they're easier to make, they're flexible, co

Shell scripts are a more evolved form of programming and nobody can change my mind on that. They require less work, they're easier to make, they're flexible, compatible, composable, portable, small, interpreted, and simple. You can do more with few characters and do complex things without the complexity of types, data structures, locks, scoping, etc. You don't write complex programs in it, but you use complex programs with it, in ways that would be over complicated, buggy and time consuming in a traditional language. That said, it's a tool. Like any tool, it depends how you use it. People who aren't trained on the tool, or don't read the instruction manual, might get injured. I'd like to see a version of it that is safer and retains its utility without getting more complicated, but it would end up less useful in many cases. Maybe that's fine; maybe it needs to be split into multiple tools.

alanbernstein 2y ago
I agree with most of this, my biggest issue is how hard it is for me to recall any moderately complex shell syntax (or the slightly different Makefile syntax). LLMs largely solve that for me.
- throwaway458864 2y ago
  The bash man page is my bible. It's dense and long but it always has the answers, you just gotta know where to look.
  - nocombination 2y ago
    When people mention `bash` it's immediately a code smell. In order to write portable shell scripts, it must be only POSIX `sh`. If the need ever arises for a more complex data structure, typically I jump into AWK since it's also POSIX compliant. Here's a note from the Ubuntu recommendation: https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh
    - 10000truths 2y ago
      I've never been in a situation where I had to care. Bash is everywhere, it's a de facto standard of its own. Even a lot of buildroot and Alpine based Linux deployments, which don't come with bash by default, usually have bash added to them.
      - Gud 2y ago
        It’s not everywhere though, FreeBSD for example doesn’t use it.
        10000truths 2y ago
        It doesn't come with bash pre-installed, but installing it is as simple as "pkg install bash", and that is the option that everyone working with FreeBSD will choose when they encounter a shell script that only works with bash. My point is that bash is already so ubiquitous that almost no one is going to care about an extra few megabytes for the bash executable in their OS image.
        justaj 2y ago
        If you're installing packages anyway, then why not just write in Python, Go, or any other languages which have relatively less footguns and have more features? I'm sure at least some of those packages are also available on FreeBSD.
    - throwaway458864 2y ago
      Not every shell script has to be that portable. And even then, "POSIX compatible" shells vary in their "POSIXness". Sometimes using arrays is the right thing to do, or having a reliable indicator of the source script location, so you code to Bash 3. Sometimes associative arrays or something else is better, and your platform is known, so you code to Bash 4 or 5. Maybe all your users are Zsh users so you use that. So you can start by writing POSIX compatible scripts, but there's no sense in tying your hands if you don't need to. The Bash manual also covers POSIX semantics, I just remember which is which. You're right that the Dash manual is a good place to check what is mostly POSIX (Dash isn't actually strictly POSIX). I would probably use Shellcheck with the correct shebang to double check what's compatible.
- JTbane 2y ago
  I would RTFM so I actually learn something instead of using """AI""" regurgitation.
  - alanbernstein 2y ago
    I find the manual for bash to be a terrible way to learn things
  - red-iron-pine 2y ago
    man pages are great if you already know 100% what you need to do, and just need a refresher. but if you don't, and the tldr command isn't available, then good freakin luck.
    - epiccoleman 2y ago
      `curl cheat.sh/$command_name` usually works pretty well! (as long as you've got curl, of course)
twic 2y ago
I have written a lot of bash. When you know what you're doing it's very productive. But it still feels like walking a tightrope, where some corner case in quoting, interpolation, comparison, etc will one day rm -rf / you. What i really want is "python, but with really easy running of subcommands". Imagine extending python with a $ operator (prefix, applied to iterables) so that files_iter = $('ls') would run ls and put an iterator over its lines of output in that variable, throwing an exception if ls exits with an error status (i realise there is a rabbithole of subtleties here - getting those right would be part of this). Or contains_pattern = $?('grep', '-q', pattern, file) to get just the exit status as a boolean. I think i'd drop bash in a heartbeat.
- arp242 2y ago
  Languages like Ruby, Perl, and PHP have a backtick that can be used for that; for example in Ruby: >> files = `ls / | grep ^b`.split("\n") => ["bin", "books", "boot"] >> p $? #<Process::Status: pid 10889 exit 0> >> `false` => "" >> p $? #<Process::Status: pid 10898 exit 1> I don't use it a lot because I don't feel like installing Ruby just for a few scripts, and zsh solves enough of the problems for me anyway. Also parsing ls output isn't necessarily a good idea, and what you really miss is "first class globbing" like: for f in /b*; [..] arr=(/b*)
  - twic 2y ago
    Backticks are going in the right direction, but not quite it. I want to operate on lists (or iterables etc), not strings, so i have all the usual safe and convenient facilities of the language available to build them. I want to get an object back that is extremely easy to get various kinds of results out of (Python's subprocess object isn't; i'm not familiar with Ruby's). I want more aggressive raise_for_status style error checking. Thinking about it, this doesn't need to be an operator, and i could probably just write this myself and start trying it. Interesting point about globbing. My feeling is that i don't actually use it a lot in scripts - the criteria for matching are usually complicated enough that i'm much more likely to use find. In a project with 1376 non-comment lines of shell script, i found eleven uses of globbing.

alanbernstein 2y ago

I agree with most of this, my biggest issue is how hard it is for me to recall any moderately complex shell syntax (or the slightly different Makefile syntax). LLMs largely solve that for me.

throwaway458864 2y ago
The bash man page is my bible. It's dense and long but it always has the answers, you just gotta know where to look.
- nocombination 2y ago
  When people mention `bash` it's immediately a code smell. In order to write portable shell scripts, it must be only POSIX `sh`. If the need ever arises for a more complex data structure, typically I jump into AWK since it's also POSIX compliant. Here's a note from the Ubuntu recommendation: https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh
  - 10000truths 2y ago
    I've never been in a situation where I had to care. Bash is everywhere, it's a de facto standard of its own. Even a lot of buildroot and Alpine based Linux deployments, which don't come with bash by default, usually have bash added to them.
    - Gud 2y ago
      It’s not everywhere though, FreeBSD for example doesn’t use it.
      - 10000truths 2y ago
        It doesn't come with bash pre-installed, but installing it is as simple as "pkg install bash", and that is the option that everyone working with FreeBSD will choose when they encounter a shell script that only works with bash. My point is that bash is already so ubiquitous that almost no one is going to care about an extra few megabytes for the bash executable in their OS image.
        justaj 2y ago
        If you're installing packages anyway, then why not just write in Python, Go, or any other languages which have relatively less footguns and have more features? I'm sure at least some of those packages are also available on FreeBSD.
  - throwaway458864 2y ago
    Not every shell script has to be that portable. And even then, "POSIX compatible" shells vary in their "POSIXness". Sometimes using arrays is the right thing to do, or having a reliable indicator of the source script location, so you code to Bash 3. Sometimes associative arrays or something else is better, and your platform is known, so you code to Bash 4 or 5. Maybe all your users are Zsh users so you use that. So you can start by writing POSIX compatible scripts, but there's no sense in tying your hands if you don't need to. The Bash manual also covers POSIX semantics, I just remember which is which. You're right that the Dash manual is a good place to check what is mostly POSIX (Dash isn't actually strictly POSIX). I would probably use Shellcheck with the correct shebang to double check what's compatible.
JTbane 2y ago
I would RTFM so I actually learn something instead of using """AI""" regurgitation.
- alanbernstein 2y ago
  I find the manual for bash to be a terrible way to learn things
- red-iron-pine 2y ago
  man pages are great if you already know 100% what you need to do, and just need a refresher. but if you don't, and the tldr command isn't available, then good freakin luck.
  - epiccoleman 2y ago
    `curl cheat.sh/$command_name` usually works pretty well! (as long as you've got curl, of course)

twic 2y ago

I have written a lot of bash. When you know what you're doing it's very productive. But it still feels like walking a tightrope, where some corner case in quoting, interpolation, comparison, etc will one day rm -rf / you. What i really want is "python, but with really easy running of subcommands". Imagine extending python with a $ operator (prefix, applied to iterables) so that files_iter = $('ls') would run ls and put an iterator over its lines of output in that variable, throwing an exception if ls exits with an error status (i realise there is a rabbithole of subtleties here - getting those right would be part of this). Or contains_pattern = $?('grep', '-q', pattern, file) to get just the exit status as a boolean. I think i'd drop bash in a heartbeat.

arp242 2y ago
Languages like Ruby, Perl, and PHP have a backtick that can be used for that; for example in Ruby: >> files = `ls / | grep ^b`.split("\n") => ["bin", "books", "boot"] >> p $? #<Process::Status: pid 10889 exit 0> >> `false` => "" >> p $? #<Process::Status: pid 10898 exit 1> I don't use it a lot because I don't feel like installing Ruby just for a few scripts, and zsh solves enough of the problems for me anyway. Also parsing ls output isn't necessarily a good idea, and what you really miss is "first class globbing" like: for f in /b*; [..] arr=(/b*)
- twic 2y ago
  Backticks are going in the right direction, but not quite it. I want to operate on lists (or iterables etc), not strings, so i have all the usual safe and convenient facilities of the language available to build them. I want to get an object back that is extremely easy to get various kinds of results out of (Python's subprocess object isn't; i'm not familiar with Ruby's). I want more aggressive raise_for_status style error checking. Thinking about it, this doesn't need to be an operator, and i could probably just write this myself and start trying it. Interesting point about globbing. My feeling is that i don't actually use it a lot in scripts - the criteria for matching are usually complicated enough that i'm much more likely to use find. In a project with 1376 non-comment lines of shell script, i found eleven uses of globbing.