> Libraries are 'compiled collection of object module', can be static/dynamic, > dynamic imply a runtime load.
By this definition, dynamic languages and scripting languages don't have libraries. They clearly do have libraries. Sometimes they're called modules but it's the same thing. > This is valid for interpreters with JIT compiler that can produce librairies. It's also valid for code that's not compiled at all. > Bash do have libraries by means of loadable .so files, .so files can > legitimatly called libraries. Those are called shared objects, as implied by the .so extension. Bash documentation also calls them shared objects, not libraries. https://www.gnu.org/software/bash/manual/html_node/Bash-Builtins.html#index-enable > The -f option means to load the new builtin command name from shared object > filename, > on systems that support dynamic loading. Bash will use the value of the > BASH_LOADABLES_PATH > variable as a colon-separated list of directories in which to search for > filename. Shared objects can also be executables. The dynamic linker is an example. /usr/lib/ld-linux-x86-64.so.2 --help Usage: /usr/lib/ld-linux-x86-64.so.2 [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] You have invoked 'ld.so', the program interpreter for dynamically-linked ELF programs. Usually, the program interpreter is invoked automatically when a dynamically-linked executable is started. You may invoke the program interpreter program directly from the command line to load and run an ELF executable file; this is like executing that file itself, but always uses the program interpreter you invoked, instead of the program interpreter specified in the executable file you run. Invoking the program interpreter directly provides access to additional diagnostics, and changing the dynamic linker behavior without setting environment variables (which would be inherited by subprocesses). Note how I had to use the full path to the linker in order to invoke it. It's a library. It's not in the PATH. And yet it's an executable. You can have perfectly normal executables whose functions you can link against and use as though they were themselves libraries. With GCC, you make them by passing -fPIC -pie -rdynamic to create a position independent executable which includes all defined symbols in the ELF table, not just the used ones. The result of that is an executable whose symbols can be looked up, linked and relocated. In other words, a library that can also run. As you can see, the lines can be quite blurry indeed. When it comes down to it, the only difference between an executable and a library is whether it does something useful when you run it directly. The presence or absence of an ELF entry point for the program. The existence of a main function. In scripting languages, the main function is implicit. The code is usually interpreted line by line by a virtual machine. This interpretation essentially is the main function. Functions are defined dynamically as the interpreter moves through the code. So the only way to distinguish libraries from executables is to look at the what the code does and interpret its purpose. Does it just define functions and exits? That's a library. Or does it actually do something with those functions? That's an executable. > A 'script' is a bash source file with the +x bit set (executable) https://en.wikipedia.org/wiki/Scripting_language > In computing, a script is a relatively short and simple set of instructions that typically automate an otherwise manual process. What are scripts called when they automate no tasks and contain nothing but function and variable definitions? I call them libraries.
