Why does nobody write programs in shell/bash? they seem to be much simpler that c, java and all that other shit

why does nobody write programs in shell/bash? they seem to be much simpler that c, java and all that other shit

Other urls found in this thread:


Because scripts change syntax based on the shell program you use to interpret them with.
Which is faster as it directly calls assembly instead of system commands. But less configurable unless you import files or make them readable.
Codemonkey shit for pajeets. Don't use it.
Such as?

Well some do, FreeBSD's portmaster program is in pure bourneshell. They're really awful languages though, and doing anything other than glue code with them is beyond what they were intended for. You can write fairly complex programs in awk, but no one does this.


Only use it when it's really faster to do it that way, and never when you want robustness. And you need to know your shit, or you'll leave more vulnerabilities than a C program in.
tl;dr try your scripts with a file named "hello\n'\t&world '

Shellscript is almost impossible to write correct software with. It's the land of 80% solutions and error handling. Avoid it.

I've written (small) nontrivial programs in shell before like this site's old anti-spam system, jesus fuck that was a mistake.
It's alright for gluing other programs together, but when you do even slightly complicated things it becomes a nightmare.
You're looking for a more general-purpose scripting language, like Python.

if the only thing you want to write is Hello World™, then yes.
but if you do not understand any formal theory of programming languages and see no problems with bash, you are free to try to write something nontrivial in it (and experience a lot of pain)

if you have access to bash then you have access to perl which is always a better choice

even this one is one hell of a language wart

Most shells are sh compliant

lol no
You should really only be using shell scripts to automate series of shell commands that you would normally do.

Fuck, I never realized this. That's a lot of buggy shell scripts I must have written.

'trivial' doesnt mean 'bad' or 'useless' mind you.
simple shell functions and scripts are wonderful.

also, there are a lot of things one might want to do that SHOULD be in shell, and should not be in python or perl or whatever, because they are(or can and should be) very simple and achievable by gluing programs together with a little bit of flow control, and using a general purpouse programming language would be retarded.
for example, I was once looking to convert some .hgt files(heightmap data from nasa sattelite missions) to images. Some blog I found described doing it with python. not as practice using python, just as the way to do it.
but, theres already a set of tools for converting those files into images. gdaldem tools or whatever. and composing them with imagemagick or something is just a sequence of commands. automating it is just stringing the commands together and keeping track of the files involved with a variable. doing it in python for any reason other than practice is retarded and unnecessary.

Use the right tool for the job. The shell was made for gluing programs together and that's what it is best at. It's like duct tape in that regard, but just as you quickly reach the limits of what can practically be achieved with duct tape, so do you quickly reach the limits of what makes sense in the shell. gets it: if you have many small programs that do some of the work already, then just glue them together. If you need to actually write something new, then use a real programming language. Don't let the simplicity of the shell fool you, for complex tasks it will actually be harder to solve them with the shell.

You can set the shell in the shebang:
Writing for the Bourne Shell is preferred for portability, but if you need Bash features you can tell the system to use Bash.

if you're writing for yourself on your personal machine, and noone else is gonna read it, you should just use your interactive shell for scripting.

Isn't there no guarantee of portability even if you do write it for the POSIX bourne shell?

People do. That's half the point of bash. It's pretty damn good at gluing together other programs but you must have some kind of brain damage to write anything big in it.


I actually never learned sh/bash/ksh because of this, in part.
not fi and esac specifically but just them being ugly, in combination with ksh/bash having a bunch of features, so when I went to the manual to find out how to do something I just found that one thing and forgot about it later, never read the whole page.
I ended up learning rc when I tried it out, since its syntax is easier and its manpage is small enough I ended up reading all the way through it after a few times consulting it. would reccomend.

Bash syntax is fucking awful and it's much easier to just write a script in python most of the time. Anything > 50 lines should be written in C/C++ anyway.

Because shell scripts have terrible syntax and anything involving floating point integers quickly becomes convoluted.

There's no guarantee, because of bugs or deliberate non-compliance with POSIX. But you can get maximum portability by writing for plain Bourne shell, and using only the utilities (and their options/arguments) described in POSIX:
This was my strategy some years ago when I had to write a script for managing hundreds of systems already in the field, each with unknown versions and distros of Linux. The only thing I could be sure of is that they'd eventually download my script and execute it, but nothing else was guaranteed, and there was no way to find out any more details about them (they were located all over the damn place, thousands of miles apart).
One caveat though: if you examine the list, you'll notice that it's missing a lot of basic networking utilities: no arp, ping, route, netstat, ifconfig...
Another thing: if you have to deal with BusyBox, POSIX probably won't help you much.