Dtyjlui

The last answer was quite good to understand what is binary or config file in linux.
So question is why do we needed to create a binary file for ls command or other binary config file for linux system. just like we made config file to perform a specific a task why we didn’t make config file for ls command and other binary files.

I think you are not only confused about config files and binary files but also about config files and scripts. Let me show a very simple example and start with a config file:

Config file hello.conf

WHAT=World

This simple text file just sets a configuration variable. It sets the variable WHAT to the value World.

Now consider a simple script file that uses the value defined in the config file hello.conf.

Script file hello.sh

#!/bin/bash



source hello.conf

echo "Hello, $WHAT"

The first line tells the OS how to handle this file. In this case it will be run by the /bin/bash program. bash knows the syntax we use in this script and acts accordingly. That is: it sources (=reads) our config file hello.conf and then is able to use all the definitions we made in that file. Next, it echoes the string Hello, followed by the content of the variable $WHAT from the config file. If we run that script, we get:

user@host # ./hello.sh

Hello, World

Now we could change the config file to contain, for example, WHAT=Jim instead. We can now run the very same script file without any change but it will now print

user@host # ./hello.sh

Hello, Jim

So config files are a way to change the behaviour of programs without touching the programs themselves. This separation of data and code is an important step in programming as it helps keeping the code clean and independent of the data.

Now for something more complicated: A binary file. I've written a simple program in a programming language called C. The special thing about it is that we first write source code in a text file and then translate (we say compile) that text file into a machine readable (binary) form. This binary form is no longer human-readable (well, at least not easily), but the machine can read it perfectly.

C source file hello.c

#include <stdio.h>

#include <string.h>



int main(void)

{

    FILE *file = fopen( "hello.conf", "r" );

    if (file) {

        char line[1024];

        char what[256];

        while (fgets(line, sizeof(line), file)) {

            if (sscanf(line, "WHAT=%s", what) == 1) {

                printf( "Hello, %sn", what );

                break;

            }

        }

        fclose(file);    

    }    

    return 0;

}

As you can already see, this is far more and more complicated code than we used for the hello.sh and I already omitted error handling to simplify it. However, this code is of no use to the OS. We first need to compile (translate) it into a machine readable form. That's what compilers are for and I'll use gcc (a standard C compiler) here. So:

user@host # gcc hello.c -o hello

user@host # ls -l

-rwxr-xr-x 1 user user 8536 Jan  6 12:43 hello

-rw-r--r-- 1 user user  423 Jan  6 12:16 hello.c

-rw-r--r-- 1 user user   11 Jan  6 12:18 hello.conf

-rwxr-xr-x 1 user user   60 Jan  6 12:26 hello.sh

The compiler produced the binary file hello (without any extension) and we can now execute that:

user@host # ./hello

Hello, Jim

Now we can again change the definition in the hello.conf to change the behaviour of our binary program hello without changing the source code and re-compiling it. I could now send that binary hello without the C source code (hello.c) to someone else and he can execute that binary together with a proper config file hello.conf.

Binary files (like a compiled C program) and script files (like bash scripts) have various differences, some of which are:

• Binaries are (almost) immutable, i.e. a
  user cannot change the code they execute (only
  the data they operate on). They behave as they
  were written and compiled.


• Binaries usually run faster
  than scripts because the syntax check and has
  already been done at compile time (just once).
  The compiler will also optimize the code while
  translating to run even faster.


• Scripts on the other hand are
  evaluated (checked) each time the script
  is run. This can take time.


• Scripts are human-readable, i.e. a user can look into
  a script and tell what it does.
  This is not easily possible for binaries as you already
  noticed. Without a really deep, deep knowledge of the machine
  readable code you cannot tell what the binary actually
  does. You have to believe what the documentation says or
  what the programmer told you.

The last item is where Open Source kicks in: the idea is that binaries are shipped together with the source code so a user can see the source code and compile the programs himself. Closed Source software on the other hand just ships with the binaries.

I think you're a bit confused about what configuration files do, and what programes (commonly referred to as binaries) actually do.

Binaries or programs are programs that do something. They actually are executed, and the statements evaluated. That may be as simple as 2+2, or more complex, such as ls, which lists contents of current directory.

Configuration files modify what programs do. For instance ls may be configured to show colors, columns, and so on. The program ls supports all these things, but they can be activated or deactivated depending on configuration.

For more complex programs, such as apache, which is a webserver, the configuration files may change behaviour of the program to an extreme degree.

Programs are not configuration files, and configuration files are not programs. A configuruation file does not perform any task, it instructs some program on how to behave.

It depends on the application and the author of the software. If the author intended the application to have various configuration parameters for user, they can either let the user supply command-line arguments that change application behavior, or there can be config files to keep that information for future use. Many applications such as services and daemons need configuration files at boot because the config files will provide all the necessary information for service to perform its task. Controlling hardware, such as assigning stating IP to network card, is much easier and shorter with config file rather than doing that each and every time by yourself.

As for ls, it's just due to history. Original ls did one and only thing - list files in the directory and creators didn't intend it to have config files, although it does have command-line arguments. POSIX standards makes ls as one of among basic commands required to be supported by Unix-like operating systems, and Ubuntu does provide ls to adhere to the standard. However, if someone wanted to make ls which implements POSIX features and also uses config files - they could very well do that.