Understanding the fork system call in Unix

> The vfork() function shall be equivalent to fork(), except that the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit() or one of the exec family of functions.

This roughly simplifies to "the only safe thing to do after a vfork is exec", and in this decade you can use posix_spawnp for that instead.

In particular, you can't do safely do anything that you'd normally want to after forking, like closing fds or moving them around (that'd be "calls any other function"). This means that unless the executable you're execing into is also under your control and knows what it's getting into, you have to mangle your fds &c. in the parent, vfork-and-exec, then undo the mess you've just made.

It is in principle _possible_ to navigate this error-prone process without observable side-effects. (The same could be said about implementing speculative execution, and look where we are now.) But I would hesitate to call it correct; the approach is clearly wrong, even if the result looks okay..

The situation is only slightly better if you're targetting some particular OS, which can provide stronger guarantees.

So does every tutorial which doesn't check the return from printf or check for errors from cout. Did you notice that the parent and child are both writing to the same file descriptor? Maybe the writer should add some words and tests in his code about the inherent race condition there. A true pedant would push this even further and teach their audience how to eliminate this problem with cross process mutexes or semaphores. Better be sure to check the error codes on those calls too.

I know arguing with a pedant is like wrestling with a pig, but honestly I'm more offended by the "#define N 2" than by the lack of error checking.

  $ echo $((1*2))
  2
  $ string="hello, world"
  $ echo ${string/hello/goodbye}
  goodbye, world

It's a single command in bash, invoking a program far more efficient than anything you can put together in python. It is literally a tool written for this exact purpose. I think it is simply ridiculous to not use a pre-existing tool that frankly you cannot out-do with a scripting language.

Even if you are writing a python script, you should _still_ use find to search for files if there is _any_ complexity in the search requirements.

Look. We are working an professional field with a strong scientific foundation. There is no "this bridge is harder to drive over for me therefore I think it's bad architecture". The easiness and expressiveness depend on the problem you try to solve, not on the people, their tastes or their experience.

Shell tools are highly optimized to work in pipes, to work on files and to work on line separated entries like lines of code or lines of CSV. So if you have a problem where you need to pipe file handling into some filtering and into some line based transformations then you will have a hard time to find anything as easy or expressive as a bash script. And most projects on a unix-like operating system at least start like this: Understand the problem based on database dumps, logs, csv data measurements, previously written code etc.

If your regular expressions are not able to cover all the edge cases anymore and/or become unreadably complex then of course you should start an actual program. That only happens a few weeks into most topics though.

> doubly so when you need to throw more of them at this thing written by a former developer that thought he or she was saving money for the org by not spending an extra 30 minutes writing the program in Python or Go.

Yes, there are people who lack the skill or ambition to develop good code. We all hate when we need to deal with their stuff. But honestly, would they have written better code if they had used Python or Java or C++ for that problem? Unlikely.

A good coder would have some feeling for when he outsources some functionality to a python script. And if he develops a code base for a longer time most of his code will be in a real programming language. But even then it might be wrapped into a thin layer of bash to use find or grep or something that cleans up the input a little.

    #!/bin/bash
    # run this scri0t with 0 or more filename args
    for file in "$@" ; do
        do_something_with "${filename}"
    done

From the man page bash(1):

    Special Parameters
       @  Expands to the positional parameters, starting from one.
          When the expansion occurs within double quotes,
          each parameter expands to a separate word.
          That is, "$@" is equivalent to "$1" "$2" ...

In any case I don't say put in a Bash script and let it grow to ten million lines over 20 years.

My approach to bash scripts is this:

1. start with a bash script to understand a problem and see how a solution might be structured. PoC level is enough here.

2. When you know you solve the right problem and the customer is willing to make something bigger, then put ~80% of the code in a good programming language (Python is my personal favorite, but Ruby, Java, PHP, C#, C++, Lisp might also work). That happens about 3 months into a project.

3. If you start to hit bottlenecks and performance ceilings put the 30-50% that are relatively stable and most performance hungry into C/C++ code and really optimize the heck out of it. This should be done only with an aged project, like 2 years in, and very pessimistically, since highly optimal code usually is badly readable and badly maintainable. You certainly don't want to go into that code 6 years later and drastically change its API to your python code.

So a ten year project would have a thin layer of bash/docker at the top, a strong core of highly flexible code (of Python for me as well) in the middle, and a leg of high performance C code here and there.

I honestly have never seen a project that really needed the C-layer though. In modern IT world it seems most problems are old at least from a political/management point of view between 2 weeks and 3 months. So in fact, although I count myself as a Python coder, the last few years I've spent writing way more bash and docker related stuff, which then is either never touched again or directly thrown away after a few weeks, no matter if successful or not.

PS: Please don't use spaces in file names. Not just for scripts. It is also not clear for users where something ends, and they are even less used to putting string indicators around file names than you are about handling spaces with bash there.

And last but not least stuff like spaces in filenames, starting scripts with upper case letter etc, they might even be just a small annoyance. But you can be sure that skilled developers will put you 2 classes below their average when they see this, because it simply shows a lack of the right spirit.

And good for them! What kind of savage puts spaces on their filenames?

Shell scripts are good for gluing together tools that do disparate things and simple automation. Most shell scripts end up becoming "real programs" once they start containing actual logic in them.