what would you use to replace Bash for scripting?

[MMMarco]

Bash is good, but it's too error prone.

What would you use to replace it?
(excluding big elephants like Python, which I like, but it consumes too many resources)

Php ... well, it looked a good idea, after 1 year, let me say: never again!
Lua? eLua?
...

Looking for something I can use to replace my startup system scripts (/etc/init.d/*), as well as my system scripts (in /usr/bin/), currently all written in Bash-scripting.

For purely synchronous tasks that don't need much parallelisation PHP is a good choice.

If you can stomach the error handling that is, and don't need modularization (PHP sucks at those).

Otherwise, I'd use nodejs because it enables very powerful parallelisation and modularization without much effort (think async/await and import/require).

And ...

Php ... well, it looked a good idea, after 1 year, let me say: never again!

I know where this is coming from and this is the reason I'll be migrating ALL my scripting/building/tooling scripts from PHP to JavaScript. (see my points above)

[linux-works]

in the bay area, if you do anything that's not C or C++, its python.

end of story.

[sokoloff]

There is a massive amount of javascript (react and node) being written in the valley.

I'd be surprised if c, c++, and python added together represented even 40% of the code written in SF, the valley, California, the US, or the world.

[paulca]

I found it hard to explain and produce examples, as it's not the "first" evaluation of the space and other delimiter containing data that is an issue.  You can just "" quote it.

However, every bash evaluation of a quoted string, unquotes it.  So if it then passed as an argument to a program in teh script it again loses it's "single argument" nature.

#!/bin/bash

stuff=$1
mplayer $stuff



Then calling it with:

./script.sh "My movies.mpg"

Will usually result in
My:  File not found
movies.mpg: file not found.

There are syntactic sugars which I believe can change how base expands or does not expand the quotes, but I never remember them and they are hard to google.

[Picuino]

Sometimes it can be interesting to have a C language interpreter that does not need to compile the sources. TCC is the answer: https://bellard.org/tcc/

Lua is very lightweight and portable, if that's what you're looking for.

Python without libraries can also be lightweight. And, although the battery-powered language is a bit heavier, for some reason it comes standard in most major Linux distributions.

AWK is another option. I used it a lot to automate some tasks before I got to know more "Heavy" languages like Python.

Another option is TCL: https://www.tcl-lang.org/

Edit:
Last, but not least. Javascript.

[SiliconWizard]

TCC is great and can be used as an interpreter, but it compiles so fast anyway that you can even use it in similar ways as an interpreted language while still running compiled code.
It compiles a several KLOCs C file faster than Python takes to initialize.

[Nominal Animal]

However, every bash evaluation of a quoted string, unquotes it.  So if it then passed as an argument to a program in teh script it again loses it's "single argument" nature.

#!/bin/bash

stuff=$1
mplayer $stuff

Yes, that is absolutely true.  The only "fix" is to use proper quoting within the scripts everywhere (so stuff="$1" and mplayer "$stuff" in the above example).  The nice thing is that after you do do that and it becomes second nature, you know your scripts (like mine) can handle all possible filenames in Linux, even those including newlines or other control characters.

Bash (and POSIX sh) shell script language is a funky beast, and double quotes should be considered syntax for disabling word expansion; similar to how single quotes disable all mangling and expansions.

My typical work scripts begin with
    #!/bin/bash
    export LANG=C LC_ALL=C
    Work="$(mktemp -d)" || exit 1
    trap "rm -rf '$Work'" EXIT
where setting LANG and LC_ALL ensures non-ASCII bytes in names are treated as-is and not attempted to parse according to the locale charset, and the last two lines create a temporary work directory that is autoremoved when the script exits (even if killed by a signal or some other error).  The quote order in the fourth line means the work directory path is expanded on that line, when the trap is set, so that even if the variable is modified later on, the original work directory gets removed.

If the script deals with globbing files, I insert the shopt -s nullglob before the export line, so that glob patterns that don't match anything, expand to an empty string (instead of the pattern itself as is default).

One really needs to read (most of) the Bash manual, and grok its idiosyncracies and inanities, before one can learn how to write reliable Bash scripts.  I agree that to many, it is just too much effort compared to how little it is used in real life.  I've written quite a lot of Bash code myself, including a bespoke init system for benchmarking compute nodes, so I basically had to spend the time to learn it well.

A good example of the hidden complexity and gotchas is the following Bash snippet, and why it outputs nothing:
    X="" ; echo foo | read X ; echo $X
The fixed version that does what one would think is
    X="" ; echo foo | ( read X ; echo $X )
but X is still empty afterwards.  The recommended version is
    X="" ; read X < <( echo foo ) ; echo $X
where X is foo afterwards.  A normal user or sysadmin does not need to know this, unless they write a lot of maintenance or init scripts.

(The reason for the behaviour is that right side of pipe, |, is always in a subshell, and changes to variables in a subshell are not propagated to a parent.  Parentheses form a subshell, so in the second variant the echo is in the subshell and not the parent.  The third form executes the echo foo command in a subshell, and redirects it as the input to the read built-in in the parent shell; this is why the feature was created in the first place.  The first < is the input redirection, and the <(...) creates a subshell redirecting its output to a pipe, and in the parent shell evaluates to the path of the other end of the pipe, that is in Linux only valid for that process and not readable by any other processes.  echo <(true) typically outputs a descriptor-based path in Linux, /dev/fd/NN; the path would only work for that echo process, and not any other, so there is no risk of leaking the pipe contents.)

[DiTBho]

Yesterday my bash libraries reached 12K lines of code.
Not for hubris talking, but this stuff is unmanageable.

So, I am going ahead for inertia, but I am already moving to Lua.

10% progress 

[Nominal Animal]

Yesterday my bash libraries reached 12K lines of code.
Not for hubris talking, but this stuff is unmanageable.

So, I am going ahead for inertia, but I am already moving to Lua.

10% progress 

Hey, I always recommend people use whatever tool that works best for them, as long as the tool is suitable for the problem at hand; and Lua is a widely used scripting language.
While I haven't seen what Lua would look like when used to implement command-line utilities, I don't see any reason why it would not be suitable here.

If nothing else, it is an interesting experiment.  I do a lot of stuff just as an experiment myself: it's the best way to find out and learn.

[MMMarco]

Yesterday my bash libraries reached 12K lines of code.
Not for hubris talking, but this stuff is unmanageable.

So, I am going ahead for inertia, but I am already moving to Lua.

10% progress 

You truly have earned my respect for this  well done! I'm doing something similar, moving from PHP to all JavaScript 

Hey, I always recommend people use whatever tool that works best for them, as long as the tool is suitable for the problem at hand; and Lua is a widely used scripting language.

That's solid advice, but one has to keep in mind that (in some cases) they're locking themselves into a language.

For example, I actively try to avoid anything from Google and Facebook because I don't trust these companies.

Doesn't need to be the case, as DiTBho is showing right here. Kudos to him for biting the bullet and move to an another language!

[SiliconWizard]

Yesterday my bash libraries reached 12K lines of code.
Not for hubris talking, but this stuff is unmanageable.

So, I am going ahead for inertia, but I am already moving to Lua.

10% progress 

Nice

[paulca]

Lua.  I believe that is a purely event based script language which either originated or gained popularity as "Game engine" script languages, very popular with modders.

I've seen it used outside of that, but the brief look into it, it seemed like one of those funky languages that does everything a little different.

[paulca]

Yea.  I'm curious.  How do you write shell scripts in Lua?

Also, if your system needs that many/much scripting to "automate" it.  It's not a very good system in my humble profressional opinion.

The analogy is giving a flight engineer a laptop to calculate the things he needs to put into the flight management systems.

Just make the flight management systems do it and fire the flight engineer entirely.

If your system has to run on the life support of so much "admin" and "maintenance" scripts, it's time to bin the system and the scripts.  Rewriting the scripts in a new language is just copying your problems to the next iteration instead of fixing them.  It's transcribing gibberish into the start of a new book. 

Dump the baggage.  Travel light.

[sokoloff]

Also, if your system needs that many/much scripting to "automate" it.  It's not a very good system in my humble profressional opinion.

The analogy is giving a flight engineer a laptop to calculate the things he needs to put into the flight management systems.

Just make the flight management systems do it and fire the flight engineer entirely.

If your system has to run on the life support of so much "admin" and "maintenance" scripts, it's time to bin the system and the scripts.  Rewriting the scripts in a new language is just copying your problems to the next iteration instead of fixing them.  It's transcribing gibberish into the start of a new book.

It seems to me that the philosophy of "use scripts to customize the interactions across different independent applications" is a good one. I can't see any realistic way to change every application to do what I want, but I can easily write scripts to move this file from here to there, copy it, make an API call, or whatever else. I have a far easier time making my Linux/BSD systems "play nice" in the way that I want and find that I often simply can't do the equivalent on a Windows machine or can't do it nearly as easily.

Eliminating scripting is eliminating user control, if not in every case at least in a lot of cases. (Or perhaps I misunderstand what you're saying.)

[Nominal Animal]

Also, if your system needs that many/much scripting to "automate" it.  It's not a very good system in my humble profressional opinion.

Your professional experience does not include systems integration, then.

Linux and BSD kernels are only a small part of the operating system.  The majority comprises of services running in userspace.  These services need to be managed, or at least started up; the kernel only initializes/executes a single userspace process as PID 1 called init.

To do this management, you have exactly two approaches: either you use a monolithic service supervisor, or you use a set of event-triggered scripts that are executed as the events occur.  (The technologically best solutions I have seen, are a mix of the two.)

Some init systems in Linux and BSD are still based on scripts, regardless of whether they use a service supervisor or not, because it turns out to be easier to configure and maintain than Windows-type binary registry database is.  Systemd uses its own format, which uses Windows-style INI files to describe the same.

Init, however, is not "all", as many applications use scripts to launch themselves (with the correct user-specific and user-locale/environment setup, typically using environment variables and command-line parameters), and many services use externally executed scripts as a way to hook into their internal events.
On my bog-standard systemd-based Linux Mint 20.3, I have 2903 executable files in /bin, /sbin, /usr/bin, and /usr/sbin.  Of these, 442 (15%) are shell scripts, totalling just under 11,000 lines of shell scripts.  Note that this does not include anything related to init, just launch scripts, so the total number is much, much higher on a typical system.  On an embedded system with a full OS but only required applications, the number is obviously much smaller, but then, the init system is best implemented as a dedicated set of scripts optimized to minimize startup time and resource usage when the system is fully running.  12kLOC of related Bash scripts isn't excessive at all for a Linux-based embedded system or appliance, in my experience in Linux systems integration.

For further information, and to get better at systems integration, I warmly recommend the Linux from Scratch project, as well as looking into the init and at least the minimum OS support services in the various BSD variants and perhaps OpenWRT, too.  The latter is widely used in routers and switches, and most manufacturers use either a custom fork, or a similar internal builds.  You'll be surprised how many scripts are used.  Yet, because the scripts are only in memory during their execution, and are easily modified to adjust to different hardware and/or use scenarios, are perfect tool for their use case.  An always-in-memory binary service would not only waste resources, but possibly also be slower and more fragile than independent scripts.

(Why, then, is systemd pushed so hard into Linux?  The original SysV init was a good design for single-core machines without too many services.  With multi-core processors, and many services and services having interdependencies, new init systems started popping up that could marshal the startups more effectively, often even in parallel, thus reducing the OS bootup startup times.  For really robust service maintenance, first service supervisors for Linux appeared in late 1990s; the one I used extensively was DJB's daemontools and a bit later, Gerritt Pape's runit.  The reason why systemd later 'won' over launchd and upstart and others, was not technical, but a business and social choice: it had the resources of Red Hat behind it.  The key factor was the Debian discussion on Init systems, which caused an avalanche effect among Debian derivatives, especially Ubuntu, which had spent quite a lot of effort in developing upstart.  This discussion and vote was not on technical merits, and was basically an example of how to use human resources to ensure you get the result you want; all of it is still available in Debian mailing list archives.  I myself prefer technical superiority over social or business superiority, so I prefer other options.  Make no mistake, systemd is nowhere near the peak of how init and service supervision can be done on current hardware; it is just the popular choice among humans.)

Would I personally want to switch from Bash to Lua?  No, not really: I have so much experience in Bash that writing robust scripts in it comes naturally, by default, for me.  Do I see the switch a bad idea?  No, because I am interested in the technical effects of the switch.  At minimum, it is an experiment I support, because I am interested in the differences to Bash/POSIX sh-based scripts.  In general, I find such experiments the only real way to find a possibly better path forward; reality and practice always trumping theories.


Apologies for the wall of text.  Systems integration (including scripts at the core of OS services and maintenance) is just a sensitive thing for me, because just like myself, it is often overlooked and completely ignored, while it is a key part of making an OS an useful tool; in Linux, the key difference between an unreliable and flaky OS and a robust, stable one (because typical kernel configurations tend to be absolutely rock solid).  No offense or belittling intended; it is just my grumpiness due to how often systems integration gets overlooked and ignored.

[SiliconWizard]

Also, if your system needs that many/much scripting to "automate" it.  It's not a very good system in my humble profressional opinion.

Your professional experience does not include systems integration, then.

Yes, or it doesn't include much work with Linux systems or similar altogether, actually.
A pretty bold and exotic statement it was.

[DiTBho]

Would I personally want to switch from Bash to Lua?  No, not really: I have so much experience in Bash that writing robust scripts in it comes naturally, by default, for me.  Do I see the switch a bad idea?  No, because I am interested in the technical effects of the switch.  At minimum, it is an experiment I support

I have enough experience with Bash scripting to say that beyond a certain level of complexity, such as the integration of all the various tools which are used from booting services to compiling an entire distro, Bash becomes counterproductive because it is too difficult to debug.

And that's where Lua comes in help, at least this is the experimental part I am evaluating.

but some things I'm writing in C, and I'm keeping them as binaries

Code: [Select]

/usr/bin/myfilename_adjust -> myfilename_utils
/usr/bin/myfilename_adjust_double_slash -> myfilename_utils
/usr/bin/myfilename_adjust_to_url -> myfilename_utils
/usr/bin/myfilename_deextendL -> myfilename_utils
/usr/bin/myfilename_deextendR -> myfilename_utils
/usr/bin/myfilename_delocal -> myfilename_utils
/usr/bin/myfilename_depath -> myfilename_utils
/usr/bin/myfilename_deroot -> myfilename_utils
/usr/bin/myfilename_desubfolder -> myfilename_utils
/usr/bin/myfilename_diff -> myfilename_utils
/usr/bin/myfilename_getextL -> myfilename_utils
/usr/bin/myfilename_getextR -> myfilename_utils
/usr/bin/myfilename_getleaf -> myfilename_utils
/usr/bin/myfilename_getroot -> myfilename_utils
/usr/bin/myfilename_majorchar -> myfilename_utils
/usr/bin/myfilename_upchar -> myfilename_utils
/usr/bin/myfilename_utils
/usr/mylib/lib_myfilename_utils_v9.o
/usr/mylib/lib_myfilename_utils_v9.h
/usr/mylib/lib_myfilename_utils_v9.interface

p.e. I wrote some Gentoo Overlays (recipe for how to compile and install the package) for utilities that manipulate filenames; all things that I can use in scripts, or even in other C files by linking with "lib_myfilename_utils_v9.o"

[Nominal Animal]

There are other indications that scripting (triggered by specific events, much like interrupt handlers on microcontrollers) will only become more prevalent and widely used, in time.

The two particular examples of this I know of, are various implementations of Berkeley Packet Filters, and Linux seccomp.  Even Netfilter (Linux kernel firewall, used as the firewall in many routers and firewalls) can be considered one form of "scripting", although it is very specific to communications.

The Linux variant of BPF, eBPF, is basically a simple binary scripting language that is run on the kernel side whenever triggered, for example at the (kernel-side) beginning of a syscall.  It is either interpreted or JIT-compiled to native machine code; security and completion checks are done at install time.  It is mostly used to construct sandboxes, so it is widely used in Android and Chromebook especially.
See the man 2 seccomp man page for usage examples in Linux.

As core counts increase, and we distribute computational tasks more and more (not necessarily to physically separate machines, but because internal buses are so short and wide that any buses between cores and bulk memory storage will still be a "bottleneck"; this is better modeled as distributed computing instead of parallel computing), I see that "scripting" using DSL's that are verified for correctness at "install"/"save" time will be needed to extract the maximum utility of such hardware.

All of these use cases have the "triggered by an event" in common.  It is not worth it to keep everything in closely coupled RAM, when each event is relatively rare, and there are huge numbers of possible events.  For systems integration at least, human readability is key for maintainability.

Bash [...] is too difficult to debug.

As far as I know, this is absolutely true.  I am not aware of any software that would help debug Bash scripts (tethered, or as a "slave" to the debugger, like one can do with binary processes and ptrace in Linux), and while it is technically possible with GDB and suitable Python accessor helpers (a whole lot of them, too), I have always done my debugging using mark 1 eyeballs only, or by treating the Bash process as I would any binary one, tracking e.g. syscalls (strace) and/or library calls (ltrace) it does, at the machine code level.

Similarly, if you write code for restricted environments with tight security requirements, validating Bash scripts can be impossible.  I definitely wouldn't want to try and do that myself.

On the other hand, because Lua implementations are embeddable with well-specified interfaces between the Lua code and the native code the interpreter runs under, it is not too difficult to develop good tools for both tasks.

Like I said, I would not do that, but I can see many reasons why someone else would, and I do support that: I do think it is worthwhile for someone to try and do this, just to find out the properties of the end result.  Indeed, because of DiTBho's reply, I now think such debugging and validation tools alone might be worth it to do this as an experiment.  (And if it succeeds, it gives completely new tools for systems integration, for high-reliability/high-security systems!)

[alm]

As far as I know, this is absolutely true.  I am not aware of any software that would help debug Bash scripts (tethered, or as a "slave" to the debugger, like one can do with binary processes and ptrace in Linux), and while it is technically possible with GDB and suitable Python accessor helpers (a whole lot of them, too), I have always done my debugging using mark 1 eyeballs only, or by treating the Bash process as I would any binary one, tracking e.g. syscalls (strace) and/or library calls (ltrace) it does, at the machine code level.

I find tracing (bash -x, and maybe also -e -o pipefail) very useful for debugging. You can also set $PS4 to add variables you want to watch.

[paulca]

Also, if your system needs that many/much scripting to "automate" it.  It's not a very good system in my humble profressional opinion.

Your professional experience does not include systems integration, then.

Yes, or it doesn't include much work with Linux systems or similar altogether, actually.
A pretty bold and exotic statement it was.

I'm sorry, but it does include a lot of Linux work and if you go and check the history on Linux From Scratch and BeyondLinuxFromScratch I was part of the team back then and wrote a few chapters of the BLFS book. "wget" nstall and one or two others where my work.

I went further to automating the whole build from scratch to reboot.

You would be surprised at how few scripts are actually used in enterprise.  They are very much limited to the very bare end of the OS.

And very, very few Unix/Linux systems use scripts for init these days.  SVInit was rewritten in C decades ago and replaced with SystemD et.al. more recently.

Most enterprise systems run supervisors and hypervisors and process management systems with agents and central control.

However, the real issue is I am a software engineer and the OP I levelled my point at isn't.  I get to say, "That's crap, lets write it again".

However if you are just taking about managing and maintaining an OS.  That's different.

If you have two applications you own/wrote and you still need significant scripts, then you need to rewrite the application to do it's own comms and maintenance.

[DiTBho]

The thing that took me the most time and that, in the end, I decided to replace with C code was dependency management.

And I wrote a library that abstracts the problem and evaluates in what order something has to be planned

At the bootstrap, /sbin/init needs to know what a service needs, and calculate the minimum path for all services, in order to have the order in which to launch them, as well as it needs to know the minimum order of services that have to shut down on an event like "ops, we lost the power line and we are on battery, less than 15 min to sync disks, close services, and shut down".

On my NAS, /sbin/init is notified by a daemon that monitors the PSU over the serial line, if the power line is lost it sends a message to /sbin/init through a special pipe, and /sbin/init reacts by invoking /etc/init.d/shutdown_on_emergency, a light version of shutdown that only cares about essential services to be safely stopped without losing/corrupting data.

At the moment, C, Bash, Lua, are all involved in this process.

Something like 2 years ago, I wrote the dependency engine all in Bash, and ... in the end, I got tired of having to debug it because it took too long, so I rewrote it in C, and not only is it faster to run but it takes 1 /10 of the time to find and fix bugs.

[MMMarco]

As far as I know, this is absolutely true.  I am not aware of any software that would help debug Bash scripts (tethered, or as a "slave" to the debugger, like one can do with binary processes and ptrace in Linux), and while it is technically possible with GDB and suitable Python accessor helpers (a whole lot of them, too), I have always done my debugging using mark 1 eyeballs only, or by treating the Bash process as I would any binary one, tracking e.g. syscalls (strace) and/or library calls (ltrace) it does, at the machine code level.

I find tracing (bash -x, and maybe also -e -o pipefail) very useful for debugging. You can also set $PS4 to add variables you want to watch.

I usually use #!/bin/bash -eufx when I don't need globbing, and #!/bin/bash -eux when I do need globbing (for some reason).

-o pipefail is ridiculous in the sense that it should be active per default IMO.

[Nominal Animal]

You would be surprised at how few scripts are actually used in enterprise.

If you limit yourself to Windows enterprise systems, perhaps.

And very, very few Unix/Linux systems use scripts for init these days.  SVInit was rewritten in C decades ago and replaced with SystemD et.al. more recently.

Init is only a fraction of the total number of scripts in any Linux installation.  Like I wrote, systemd replaced scripts with Windows-style INI files, and we can definitely argue whether it is an appropriate use of resources to A) parse those at runtime, or B) keep the parsed structures in memory.

You conveniently ignored my mention of the fact that on a bog-standard Linux installation 15% of executable binaries are actually launcher scripts, too.  I guess facts do not exist when they go against your dogmatic beliefs?

Most enterprise systems run supervisors and hypervisors and process management systems with agents and central control.

Have you actually taken a look at how common it is for these to implement the triggers as – gah! – external scripts?

Many of these do use their own scripting language – see e.g. Puppet, Ansible, cfengine, et cetera – although I guess most "sysadmins that call themselves software engineers" today expect to use GUI interfaces to these instead of dirtying their hands with the actual implementation, much less know anything about their internal operation.

However, the real issue is I am a software engineer and the OP I levelled my point at isn't.

I am starting to seriously doubt that, actually.  You make too many elementary-level incorrect assumptions and errors, and yet insist you know this stuff.
Something does not gel with the problems you discuss and your ability to solve them on your own for me to trust your skill level, especially wrt. systems integration; sorry.

I'm sure you don't trust anything I say at all either, so don't bother getting worked up: I often have the problem of people not trusting my own technical expertise.  It is some sort of presentation and communications issue I have.  This is exactly why I always give enough information to check the basis of my argument for themselves, because I don't even want anyone to trust me as an authority per se: I want them to check for themselves, and be critical of all expressed opinions.

To list the number of lines and the script name, I used
    find /usr/bin /usr/sbin /bin /sbin -maxdepth 1 -type f -perm /o+x -print0 | (T=0; while read -d "" NAME ; do T=$[T+1]; file "$NAME" | grep -qe 'shell script' || continue ; wc -l "$NAME" ; done ; printf '%d files total\n' $T >&2 ) | awk ' NF>1 { L=L+$1 ; n=n+1 ; print } END { printf "%d scripts containing %d lines\n", n, L }'
The two final lines of the output contains the useful summary.  On my Linux Mint 20.3,
    2903 files total
    442 scripts containing 109669 lines

As far as I know, this is absolutely true.  I am not aware of any software that would help debug Bash scripts (tethered, or as a "slave" to the debugger, like one can do with binary processes and ptrace in Linux), and while it is technically possible with GDB and suitable Python accessor helpers (a whole lot of them, too), I have always done my debugging using mark 1 eyeballs only, or by treating the Bash process as I would any binary one, tracking e.g. syscalls (strace) and/or library calls (ltrace) it does, at the machine code level.

I find tracing (bash -x, and maybe also -e -o pipefail) very useful for debugging. You can also set $PS4 to add variables you want to watch.

I usually use #!/bin/bash -eufx when I don't need globbing, and #!/bin/bash -eux when I do need globbing (for some reason).

-o pipefail is ridiculous in the sense that it should be active per default IMO.

Making the interpreter (Bash) more verbose, does help with post-mortem and finding out exactly what went wrong, but it isn't comparable to say single-stepping or tethered debugging (as is commonly done to binaries with gdb).

There is no technical reason why a script interpreter does not provide such interfaces – single-stepping, runtime control, state examination by an external tracer process – built-in, it is just a matter of spending the time and effort for implementing and maintaining it.  Thus far, nobody has seen the need for Bash (or POSIX shells, as far as I know).

Depending on which Lua interpreter implementation one wants to use, single-stepping and other runtime control may be already built-in to the implementation, and most likely one can run the same interpreter codebase with such debugging features enabled (to get a version of the interpreter one can use for debugging); and easy state examination is one reason why Lua is so easy to embed into e.g. C programs.  While I haven't used Lua that much, even I can immediately see how one could make a tethered interpreter, giving a GDB-like interface for run-time debugging, single-stepping, and examination of Lua state and variables, with reasonable effort.

Thinking about this further, an init service supervisor process that uses Lua scripts with the metadata (dependencies especially) as structured comments, and event management as Lua functions (to describe when the particular service fails to start), you could actually construct a robust, verifiable init system, that would still be able to launch services in parallel.

(What we really need for service supervision, is a common library interface for acknowledging service status, for example when the service is ready to accept incoming connections, stops accepting incoming connections, has mounted a new device, has removed a device, and so on.  It needs to be defined using a simple C/C++ header file, with an example dynamic library implementation that simply stubs them out, and the code to use them added to all service daemon implementations.  Of course, this means that the interface has to be compatible with all, i.e. be abstract, instead of optimized towards one specific implementation.  DBus low-level implementation is atrocious for this, because it requires several helper services, and is a single-point failure risk: not robust at all, so it is not suitable; but with a suitable shim library, one of the supported transports/mechanisms could be DBus.)

[paulca]

However, the real issue is I am a software engineer and the OP I levelled my point at isn't.

I am starting to seriously doubt that, actually.  You make too many elementary-level incorrect assumptions and errors, and yet insist you know this stuff.
Something does not gel with the problems you discuss and your ability to solve them on your own for me to trust your skill level, especially wrt. systems integration; sorry.

I'm sure you don't trust anything I say at all either, so don't bother getting worked up: I often have the problem of people not trusting my own technical expertise.  It is some sort of presentation and communications issue I have.  This is exactly why I always give enough information to check the basis of my argument for themselves, because I don't even want anyone to trust me as an authority per se: I want them to check for themselves, and be critical of all expressed opinions.

I think like most cases of technical disagreement we are talking from and about different perspectives.

You sound to me like a sys-admin and a solution integrator.  Nothing wrong with that but it's not really software engineering.  Partly, there will need to be some project engineering if it can't be done by a single person.

This is a common and repeated problem in "technical suburbs".  Just like I an a complete dweeb about electronics, most people on here think that writing code and scripts is software engineering.

People were writing code and scripts decades before we had software engineering.  Software Engineering is what happened in response to the 1960s, 1970s and beyond which was caused by spaghetti scripts, code and "single man band" projects which nobody else understood.  Literally billions of pounds is being spent STILL to this day fixing that 'ing mess.

Having 3 small applications and connecting them up with pipes, sockets etc. is fine at a low operating system level.

I haven't written an application which produced anything on standard out or standard in, professional in over 10 years.

The only shell script I have written in the past year was a very carefully constructed admin "purge" job which was ONLY commissioned because the application had been hurried/forced into release without it's own admin.

[paulca]

Inversely, for development, I am lucky enough to have changed jobs to where I can at least run more development systems locally.  As such the first thing I installed was GitBash.  Then WSL.  Then Docker. 

The target platform is linux, but I do not foresee a large amount of scripts.  Certainly not bash scripts.  Nothing exists as files for a start, there is virtual no "set down state" and the only "in memory" state is held in middle ware.  Other than starting/stopping I don't see the need for many scripts.

Remember we were talking about a single user being responsible for 12K lines of bash code.  That is what brought me to suggest something is wrong in that overall system.

I have written hobby systems in Bash alone.  Perl as well.  They are great for "admin" and "hacks" and OS integration or portability, but invariably the systems become combersome to deal with in shell and migrate to something like Python instead.