1

I ask the following question for general knowledge and to better understand modern Linux architecture. The background for this question is this session.

I assumed that if one deletes all shells, for example (rbash, bash, dash, and sh), it could still have some primal/fundamental CLUI (Command Line User Interface) to use for some very simple tasks and interact with the kernel in a minimal way. Of course, in regards to modern Linux system in general, I was wrong, because the console will only start by a login script in the shell, so, removing all shells will also remove that login script.

But what if we move that login script outside the shell, and make it part of the kernel; Would we still be able to use some primal/fundamental console then?

  • The point of a login script is to prepare the shell for use. Removing the shell removes the point of the login script. – Ignacio Vazquez-Abrams Nov 15 '17 at 3:32
  • I mean of having a console and a prompt, without the extra functionality that the shell gives it... Just a shell-less console. – Arcticooling Nov 15 '17 at 4:25
  • That's neither hard nor challenging, and doesn't require a login script. Simply specify an application to run as the user's shell. – Ignacio Vazquez-Abrams Nov 15 '17 at 4:26
  • ... I can't help but suspect you badly misunderstand how unix works. The basic assumption you refer to in your earlier session is wrong. – Shadur Nov 20 '17 at 8:59
3

Fundamentally underneath a shell is a TTY. Although it doesn't make up what you could call a CLUI. The terminal interface (text input and output) is implemented in the TTY while command processing is handled by the shell.

In DOS this is more like a batch command processor hints .bat(ch) files. While in Linux a shell is a mini programing language which also includes built in control structures.

That "login" script is actually the init program which is automatically loaded by the kernel after it loads its VFS (init can be incorporated into initram or wait until hard file systems are accessible) and it runs before ttys are loaded. In fact the init program must then setup the TTYs and then load services. sysvinit loads an interpreter shell and then uses init scripts while systemd uses INI like configuration files it calls units. A shell script is not actually needed at all during the boot process or login process but exec is.

The TTY is built into the kernel but can not interact with the user. Several commands such a login interact with the user over a TTY but are not technically command processors or shells. Other basic examples exist like the reset button on your router is technically a minimal way of interacting with the system. But any program attached to a TTY can take standard input and output from the TTY and process commands.

Ignoring the fact that you really need a shell to meaningfully interact with the system the most basic way you interact with the kernel is through system calls and the most basic one that passes messages is exec which is how command arguments are passed along.

  • A comparison to DOS probably introduces more confusion than illumination, especially when it is dated and borderline wrong (users of Microsoft's various cmds having had various control structures for almost three decades now). No, the questioner's idea of a login script is not the init program, in any shape or form. Nor are terminals "loaded" in any meaningful sense. And saying in one sentence that a system uses scripts and in the next that scripts are not needed at all, is outright self-contradictory. – JdeBP Nov 15 '17 at 12:25
  • I'm not refering to Microsofts CMD but DOS which called it COMMAND.COM Why you're referring to Microsoft escapes me as well. – jdwolf Nov 15 '17 at 16:19
  • @jdwolf I assume JdeBP is referring to Microsoft because Microsoft made the operating system we call DOS (the one with COMMAND.COM) – mattdm Nov 20 '17 at 23:52
  • @JdeBP Remember the old days when you could set a rdev in hte kernel (default root device unless one was specified elsewhere) and you could boot LILO wiht the "init=/bin/sh" argument? – ivanivan Nov 20 '17 at 23:58
  • @mattdm First of all Microsoft made MSDOS not DOS. However Microsoft was instrumental in the development and popularization of DOS. But quite simply.. CMD is clearly a Microsoft windows thing and COMMAND.COM is clearly a DOS thing so it still makes no sense. – jdwolf Nov 20 '17 at 23:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.