/tech/ - Technology★

>why does nobody write programs in shell/bash?

Because scripts change syntax based on the shell program you use to interpret them with.

>they seem to be much simpler that c,

Which is faster as it directly calls assembly instead of system commands. But less configurable unless you import files or make them readable.

>java

Codemonkey shit for pajeets. Don't use it.

>and all that other shit

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.

https://github.com/freebsd/portmaster/blob/master/portmaster

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.

See >>809304

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.

>>811290 (OP)

>they seem to be much simpler

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

>>811290 (OP)

even this one is one hell of a language wart

https://stackoverflow.com/a/174288

>>811293

>Because scripts change syntax based on the shell program you use to interpret them with.

Most shells are sh compliant

>>811290 (OP)

>seem to be much simpler

lol no

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

>>811376

>The other reason (other than empty variables) has to do with option processing. If you write:

>if test "$1" = "abc" ; then ...

>and $1 has the value -n or -z or any other valid options to the test command, the syntax is ambiguous.

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.

>>811413

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.

>>811290 (OP)

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. >>811414 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.

>>811293

>Because scripts change syntax based on the shell program you use to interpret them with.

You can set the shell in the shebang:

#!/bin/sh
#!/bin/bash
#!/bin/zsh

Writing for the Bourne Shell is preferred for portability, but if you need Bash features you can tell the system to use Bash.

>>811421

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.

>>811421

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.

>much simpler that c

<if fi

<case esac

Weak b8 and shit thread, 2/10 made me respond

>>811474

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.

>>811290 (OP)

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

>>811466

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:

http://pubs.opengroup.org/onlinepubs/009696699/utilities/contents.html

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.