[throwaway458864]

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]

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]

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]

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

[throwaway458864]

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.

[10000truths]

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]

It’s not everywhere though, FreeBSD for example doesn’t use it.

[10000truths]

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.

[Danjoe4]

Eh, bash is pretty damn portable

[JTbane]

I would RTFM so I actually learn something instead of using """AI""" regurgitation.

[alanbernstein]

I find the manual for bash to be a terrible way to learn things

[red-iron-pine]

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]

`curl cheat.sh/$command_name` usually works pretty well! (as long as you've got curl, of course)

[twic]

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]

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]

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.