On Tue, 14 Jun 2016 13:08:59 +0200, Edward Bartolo wrote:
[...]
> Now I would like to ask what is the need of the fork() call in
> Felker's code. Yes, I know, it creates a child that continues
> execution just after the fork call.
[...]
> I checked with XFCE4 loaded how many instances of felker2.bin existed
> and found that only one existed.

Since the child process is replaced by whatever program you
execute via execve() there should only be one instance left
running. What else would you expect?

Look, Edward, I admire your impetus, and your enthusiasm
surely is refreshing. But it seems I haven't successfully
put across my most important point yet. So please let me
try to bring home the message once more, at the risk of
offending you:

We could play this game day in, day out for months or even
years, without having you grasp the basics necessary to
fully understand the implications of even moderately
sophisticated C programs. It'd be like teaching integral
calculus to someone not having mastered multiplication yet:
frustrating for both student and teacher.

There is no substitute for learning things from the bottom
up. There is no silver bullet! You *have* to go through the
basics to even have a chance of understanding more advanced
concepts.

And once you've mastered at least the very basics of the
language, you can build upon that; e.g. by following
Katolaz' suggestions:
| Before coding an init system, I would probably start with coding a
| shell, with basic command execution, environment management,
| background processes, a few builtins, I/O redirection, pipes, and
| proper signal management.

I've been programming in C for decades now. I can cite C&V
from the C standard when woken up in the middle of the
night. Yet still I would never dare call myself an expert,
and I still manage to make a fool of myself when having to
deal with some of the more esoteric aspects of the language.

All of this is not meant to discourage you. On the contrary,
I'm trying to give you hints on how to go at things in a way
that gives you a fighting chance of actually understanding
what you are messing about with. Programming is *not* hitting
some code with a hammer until the compiler stops complaining,
looking for a bigger hammer if at first you don't succeed.
Programming in C is *not* about kicking a piece of code around
until it reaches some degree of 'works for me'. It is about
working responsibly and cautiously with a confusingly huge set
of delicate and (in the case of C) extremely sharp tools with
lose handles. Do like a brain surgeon, not like a hooligan!

HTH, Regards
Urban