hi~ there

i`m now very confused. the shell is for the communication between users and
the os kernel , and users can executes .sh files with its help after login.

however there`re also some .sh files that have to be executed even before login , those like scripts under rc or init . then who will cope with those .sh files at the initialization ? is there a virtual user`s shell?

only after the login does a user get a shell,right? or does the OS also use shell to communicate with itself? or the OS just has another mechanism to do the thing?

please share your opinion with me.
many thanks~

Hi,

Have a look at these 2 documents:

- Inside the Linux boot process
- The Linux Login Process

Hope this helps.

When the kernel finishes its thing it calls "init", and it does the rest of the job. "WHAT" init does depends on the concrete implementation, but it usually includes some calls to shell scripts and binary programs as well.

Shell interpreters are programs like any other. Instead of receiving clicks and that kind of thing they read commands, parse them, run whatever you ask them to run and a few other things.

The shell is not a low level thing that is used to communicate the kernel with everything else. That's the work of the system libraries. All the programs, including the shell, are built on top of the basic system libraries (that'd be glibc, uclibc or any other libc implementation in linux), which in turn ask the kernel to do something for them when needed. The shell is not required, strictly speaking. However, most init systems do have a strong dependency on shell scripts of some kind but this is merely a convention, just like it is a convention that dot files are hidden (they are not really hidden, it's just that the convention for most programs is not to show them).

Shell scripts are quick to develop, easily tweakable and human readable (kind of), and there are bourne compatible shells that are small enough to be used on randisks and very constrained environments. Using, let's say, python or perl in those cases would not be that easy.

i`ll check it out~ thank you for sharing~

i should`ve remembered that the shell script ,like other kind scripts , is just a way of sending purposes ,and the shell plays a role as translater in between. Shell can work for whoever sends it messages(thus .sh commands) , whether the sender is human user or a certain service that requires a .sh to be done in the system or even part of OS itself. Is this right?

Mostly, except that I wouldn't attribute any special or mystic role to any shell. A shell is not different to a spreadsheet, a word processor or a web browser. They all take an input and do something with it, for the OS it's really not relevant if that info is text, numbers, commands or anything else. To the kernel, any userland program (shell interpreter included) looks the same, no matter what the philosophical purpose of the program looks to our human eyes.

If you feel more comfortable, you could compare it to a GUI file explorer. A shell is aimed at doing things with files, running them, copying them, locating them, and navigating the directory tree. With enough dedication you could probably use dolphin or nautilus as your init shells, as long as you figure a convenient way to access their API from init

1 members found this post helpful.

this is an interesting question.

think of it as two different address spaces
that would be two different virtual memmory address

kernel space
and
user space

once the kernel is loaded and operational via start_kernel() basically all functionality is handed over to userspace init.
/sbin/init which is PID=1. and everything extends from that.
I think the point of confusion is "who" is the user running these user address space processes proir to innittab leading to getty and a login prompt.
The majic answer is ROOT.
root is running user space scripts.
This happens real early on while the temporary read only root file system is still in use.
the kernel then just becomes subject to user space calls.
basically at this point the kernel is only doing process scheduling and and doing low level junk (system calls) the userland processes request.
the kernel process schedular is PID=0

think of user login as a "session" on the machine. sessions have shell instances as their root process so to speak.
now when a user gets a shell instance to have a session "user@somebox.here.network"
that user actually inherits also the preexisting userland instance "root" that existed prior to them logging on and will continue to exist after they log off.

that's how i look at it anyway.

yea~ that`s my confustion.
but is the ROOT you said the same as the root-user-thing ? or simply they`re one? then how come the error "can find some files or directories"at the boot initialization when the files or directories do exist somewhere? even the root can`t access them? for example, i try to restore the configuration every time i start the machine .so i system-config-network-cmd the previous configuration and set a restoration command in rc.local. however the file is said to be unavailable during the initialization. or is this a matter with the PATH env variable?

I can't be sure what your concrete problem is. But typically, this kind of error on boot, has more to do with the scope of the current fs at a given moment. During the early stages of initialization the kernel can only access it own memory, so, anything that's not compiled statically or into an initrd can't be reached, that is, until the fs drivers get into scene, and file systems are mounted. At that point, the rest of kernel modules also become reachable. There can be other involved pieces though (RAID or LVM drivers, SATA chipset drivers, etc.).

thank u, i`ll consider the file-system thing.