My two cents
Coming to this SO question somewhat late, reading fedorqui's answer, I think "programming language" is not exactly same thing as "command language", meaning a language intended to run commands.
About Turing consideration, yes, you could... I personally wrote a lot of libraries around bash (around monitoring, backups, sysadmin, networking, etc.), but clearly for writing a program,
you have to use a real programming language.
However
bash is a shell (like sh and others shell)! Meaning an overall aggregator language, or a super language.
First goal is to be an interactive command processor,
in order to use and maintain posix systems.
One of its first applications was to create wrappers in order to prepare an environment for running programs written in other languages.
So this command processor is
ideal for systems, filesystems, networks and a lot of administration tasks, because
it's interactive and using its history makes the job of creating scripts just easy.
Its real power
As this language is intended to deal with ios, forks, fifos and because posix said everything is a file, a shell script could normally deal with everything, directly or by using other tools/binaries/applications. This language is intended to
create condition, execution groups and interaction around everything.
This could open a lot of interactivity between systems, networks, iot, etc...
A script could for example (see further my shell connector demo).
1. Open DB, SSH connection and log file simultaneously as file descriptors.
2. Create SQL (temporary or not) table
3. Doing loops, checking for events on DB, SSH connections or other things...
4. Interact with DB and/or SSH...
5. Close all file descriptors (DB, SSH, log file, etc)
Mandelbrot sample:
Comments on Mecki's answer show a good sample of how bash could be used to deal with other binaries (bc
for Mandelbrot)...
Where shell is used to run bc
and aggregate its answers.
- If a script does one fork for each calculation, this script will take many hours to draw a Mandelbrot on an 80 column terminal.
- 1st improvement: running only one background fork to
bc -l
to submit all calculations drops execution time down to 8 minutes.
- 2nd improvement: passing iterate loop (up to 2000 tests) to
bc
, drops execution time down to 8 seconds.
- 3nd improvement: creating more background
bc
for computing many dots simultaneously (parallel-processing), in order to use multi-core, dividing execution time approximately by available cores... (Thanks to Léa Gris for contributing, helping making this posix compatible, multi-core idea and adding colors, making this near beautiful, I can't resist to post their result)
More examples
I wrote some scripts showing this powerful parallelization capabilities:
- grepLogByDate Where parsing log file against time stamp could become up to 3 time quicker using bash (with at least 5 forks to
sed
, date
, bc
and paste
), than using perl.
- multiping.sh will run many
ping
simultaneously and draw a dynamic graphic using gnuplot
, while staying interactive.
- shell_connector.sh is a library if sourced but contain a full demo using
sqlite
, date
and bc
as background co-process if run.
- getSo.sh is a script intented to connect on SO server, by using openssl with authentication, cookies and Connection: keep-alive.
In order to do some monitoring, checks against differences or so one, we could create a script to open many simultaneous connections
to many differents targets, using one of netcat
, sql-client
, ftp
, open-ssl s_client
, ssh
or else...
... with the ability of running sha1sum
, grep
, xmlint
or bc
(if not already backgrounded) when required, while connections stays open...
Conclusion
shell is a super-language, useful to aggregate a complex application using many programs in various languages.