Bash as a scripting langauge and not Yet Another Programming Language?

[bowiz2]

More of a philosophical question than anything else.

The bash course seems to be heavily focused on solving relatively generic programming problems but in bash. This is akin to what Universities teach in bash courses, but falls into the same trap as being completely disconnected from it's usage in the "real world".

I was wondering what the rational behind this was - the truly valuable bash skills are usually far more related to playing with command outputs/cli interfaces/internal tooling. Getting to know grep/sed/awk/regex/argparse/file manipulation/control flow is far more important than inverting a binary tree. If I wanted that I'd use python, not a language that by design continues to execute subsequent commands after error.

It may just be me being a grumpy ops guy, but I don't see the benefit of learning Bash if not for its practical uses. It's not a programming language, it's a terminal shell that can be tricked into running a bunch of command lines one after the other.

Would love to hear your thoughts.

[IsaacG]

I believe there's a fair bit of agreement on this one. It would be great to have a shell scripting track that was more in line with actual sys admin style shell scripting.

We're just waiting for someone to build out the infrastructure to make that practical. VMs that provide the right environment, tooling to set up the environment for each exercise, test infrastructure that makes it easy to run tests and display output/failures, etc. Instructions and tooling to allow students to work either locally or via the Web UI. Cross compatibility with Windows.

Exercism is, by and large, set up to run a unit test in a particular language. That makes most languages fairly simple and straight forward to test. They also largely borrow a large set of exercises from the shared problem set.

While it would be awesome to teach shell scripting in a *nix environment, the Exercism infrastructure isn't built around that and building that all out is non-trivial.

[kotp]

Even having a docker environment or something similar that can be reset to scratch, and will not matter if your solution involves a final rm -rf / (do not do it, no joke!) invocation, and having that as a playground for doing system admin style tasks and even interactive scripts, where what is systemically evaluated is the final result, while the mentoring attends to best practices and opinions.

But I agree, though learning how to write programs in bash, I think, makes the system/admin work easier, because you now have bash as a more rounded vocabulary than only the glue that ties all of the other tools together.

[glennj]

Kind of late to the party.

The bash test runner is composed of a Ubuntu 22.04 image (list of packages), with jq, bc and gawk (and of course bats-core) added. Really, students are free to use any external program to solve the problem. (Dockerfile)

Regarding the "is it or isn't it" question, a quote from 1.2 What is a shell? in the manual:

A Unix shell is both a command interpreter and a programming language. As a command interpreter, the shell provides the user interface to the rich set of GNU utilities. The programming language features allow these utilities to be combined.

IMO, completely disagree with the "disconnected from real world usage" take.

[kotp]

I also disagree with the quote regarding "What is a shell?" specifically as it references GNU utilities. Many shells do not, though they may. Not all shells are GNU friendly, and not all systems have the GNU tools. So that document is very much, seemingly, opinionated. (just saying)

And welcome to the party @glennj

I agree about the wontfix label. Leaving it open for the discussion potential? Not sure there is anything to fix though, so not sure if it fully fits the issue.

[glennj]

disagree with the quote regarding "What is a shell?" specifically as it references GNU utilities

Well, that is from the bash manual, so naturally it is pro GNU. Of course not all shells are.

The comment does apply in the exercism bash track, as the test runner runs on Ubuntu, a GNU/Linux distro.

[bowiz2]

Coming back to this a while later, I recently came across v86, which gives x86 emulation in your browser.

You get full linux emulation with small customizable images, and lots of config options. This all happens client side as well, so aside from serving the image file there's not too much resource/cost overhead. The arch based vm is pretty convincing.

There's obviously a fair amount of implementation that needs to be done, but to be able to give a practical sysadmin style shell scripting course would be amazing.

I'm definitely willing to help with this, I have experience in bash/sysadmin course building, and don't mind doing some of the backend work necessary to get it implemented in exercism.

Let me know if you think this warrants future discussion - I'm well aware that the scope of this may be too broad to even consider, but regardless, I'm interested in what you're opinion is.

[glennj]

That's a really cool project. I don't see how it would fit into Exercism though.

[bowiz2]

I'd imagine you could script off of it - possibly instead of running the user's solution through an unprivileged server side evaluator, you could run through a client side root permission VM.

So making exercises that base off of common Linux tools and commands could be a lot simpler.

A lot of bash is working with external inputs and outputs - read a file and run commands based on it; call an api, grep for a word, if it exists then do something. Do something clever with find or kwargs or the filesystem.

There's plenty of options to explore when you have a full Linux box at your disposal, and make something that's less focused on purely programming exercises and more on bash script based solutions.

[glennj]

The bash-test-runner does use "a full Linux box": Ubuntu 22.04

There's absolutely nothing stopping a student from solving hello-world with

perl -E 'say q{Hello, World!}'

or

printf '%s\n' '' dlroW '' olleH | rev | tac | paste -sd ', !'

or sed or awk or whatever external programs exist on a default Ubuntu.

[bowiz2]

So it's possible that there's no need for something more complicated, and my original point can be brought back up- that it would be beneficial to the bash track to have more exercises teaching about different basic tools and solving more "what I would really use a bash script for" problems.

I was under the impression that there was some technical limitation that was blocking this.

[glennj]

My main argument is "what I would really use a bash script for" and "what you would really use a bash script for" seem to be wildly different.

For the app I'm working on, I have 2 cron scripts, one 125 lines one 64 lines. Both of those source a 136 bash library file. These scripts call out to grep and wc and stdbuf and other tools. They also use functions and arrays and getopts and other fancy bash stuff. Bash is a programming language that helps me get my work done.

Having said that, if you want to suggest a new exercise(s) that can showcase different unix utilities that can be invoked from bash, I'd be happy to collaborate.

Are you aware there's an awk track on exercism? I wonder if you have similar concerns about it's focus on awk as a programming language.

[bowiz2]

I suspect that's the case - my bash use cases have always been short scripts with basic control flow that get at most some passed/exported variables and then run different commands based on it.

That, or text/file manipulation for feeding into other scripts, basically just script glue. Anything longer and I shift it to python :)

I'd definitely be interested in putting something together, I'll try to get some general idea/layout and reach out to you about it.

As for awk, my experience is extremely limited (awk '{ print $1 }' and maybe an if once) so I do not have a very strong opinion about it ;)

[IsaacG]

Check out the awk track so you can write more complex awk scripts :) That might make you use bash directory for text manipulation even less!

[kotp]

my bash use cases have always been short scripts with basic control flow that get at most some passed/exported variables and then run different commands based on it.

I think that is partly the point of the track. Fluency in the Bash language means that you can go further before you have to have "Python" or some, perhaps less universally installed, other language available, along with the different versions, and features that may or may not be available on that system.

Practicing the "can you do it in Bash" and knowing "if you should" is a great balance. It is nice to have your favorite language available, but that is not always possible.

[bowiz2]

I agree, hence this discussion being mostly philosophical :)

It's not that I don't know what's possible or not in bash (done a fair amount of golfing and have the lay of man bash pretty much memorized), it's mostly just about me believing that it's much easier to write robust scriptology in a language that isn't run in a psuedoshell.

But I digress, we can discuss to no end what the purpose of bash is or isn't. I feel like a general consensus in terms of what belongs on exercism is "if you make it and it's good and fits the course, then great".

So I think we can carry on these discussions in the future PRs for new exercises :)

[glennj]

Perhaps this github issue is no longer "an issue", and can be closed.

[nielssorensen]

I agree with @glennj and @kotp; Bash IS a programming language and this Bash track is very much designed with helping people learn how to use it as such.