Posix – Linux Hint https://linuxhint.com Exploring and Master Linux Ecosystem Fri, 12 Feb 2021 01:23:49 +0000 en-US hourly 1 https://wordpress.org/?v=5.6.2 POSIX vs UNIX: Understanding the Difference https://linuxhint.com/posix-vs-unix-understanding-the-difference/ Thu, 11 Feb 2021 09:40:51 +0000 https://linuxhint.com/?p=89634

POSIX

POSIX is an IEEE standard that acts as a standard UNIX version. It is a consortium of vendors that helps users easily port applications across different platforms. POSIX is considered a subset of UNIX and is used to cover different Unix-like environments for many other operating systems. POSIX initially contained different environments, such as Eunice for Virtual Machines, POSIX Personality, and NT from Windows OS. POSIX is portable between different variants of UNIX. In general terms, we can call POSIX as an operating system of UNIX.

UNIX

Linux and GNU Project are quite like UNIX and are therefore compatible with one another. UNIX is an operating system that acts as a multi-tasking and multi-user operating system. UNIX comes with various program development tools, as well as electronic mail, text editors, etc. Many operating systems are like UNIX and have the same UI, programs, and functions. It was initially a networking operating system. UNIX was developed by a team of developers, but any other person can easily contribute to Linux and use it according to their needs.

UNIX has a trademark and is primarily used for commercial purposes. UNIX has its own flexibilities, but there is one rather famous drawback, which is that UNIX contains some hardware restrictions. Nonetheless, UNIX is a full-fledged operating system.

POSIX Commands

Software engineers and other users who work on operating systems understand that they need to interact with the command-line/terminal window of the system many times. A shell is also a powerful command-line interface, and POSIX contains a famous bash shell. In the next section, we will look at some famous POSIX commands and the purposes of these commands.

POSIX Directories

To specify the file and directory paths, use the “/” to separate directory names and filenames in the path. The following are a few sample names of paths:

Syntax Function
/ Root directory
/example Sub-directory example
/example/default A file named as default in the /example directory
~ The shortcut used to access current user’s home directory
~/someExample A file or directory named someExample located in the user’s home directory
. Leads to the current working directory
.. Leads to the parent directory

POSIX File System

The POSIX shell helps to manage several functions from one window. Users can navigate around their current location, their current working directory, and the absolute working directory (home directory).

Suppose that the present working directory is the home directory (e.g.: “/home/<user_name>”), and this directory has a subdirectory named “example.” You can use the command-line to specify this path as an absolute path (“/home/<user_name>/example”), as well as a relative path (“example”). POSIX programs executed from the shell are also aware of the working directory when declared correctly. In this section, we will cover a few sample commands and options that can be used in POSIX to move files.

Syntax Function
pwd Shows the current working directory
cd Changes the current directory to the home directory
cd /etc/example Changes the current directory to /etc/example
cd new_directory Changes the current directory to new_directory a sub-directory of your current directory
cd .. Changes current directory to the home or parent directory
cd $temporary Changes directory to the directory temporary

UNIX Commands

Now, we will check out some of the basic UNIX commands. These commands are not part of UNIX itself, but they are used in multiple UNIX machines. There is one interesting thing to take note of here: if you make a typo or error while writing in UNIX, you can use the CTRL+U shortcut from your keyboard to easily cancel out the whole line. Users can also edit these commands, which is quite easy and adaptive. Remember that UNIX is case sensitive, so make sure to take into account such requirements when trying out these commands.

UNIX Files

The first set of commands that we will discuss is files.

Syntax Function
ls To list your files, you can also use ls -l to list your files in a ‘long format’ that contains a lot of information, e.g., the precise size of the file, who is the file owner, what are the rights, and who altered the file last. ls -a lists all the files, including those whose names start with a dot, mostly are not easily visible.
more NameOfFile Displays and shows the first part of file
emacs NameOfFile An editor that allows you to create and edit files.
mv NameOfFile1 NameOfFile2 Used to move a file by giving it a different name or by moving it to another directory.
cp NameOfFile1 NameOfFile2 Used to copy the content of File 1 to File 2
rm NameOfFile Used to remove files. You can also use rm -i, which will ask for the permission of the user before deleting any files.

Directories in UNIX

The following section shows you how to use and create a directory in UNIX. The following are some of the commands used for this purpose:

Syntax Function
mkdir NameOfDirectory Used to make a new directory. Type the name of the new directory next to mkdir
cd NameOfDirectory Used to alter the path of the directory. Users can go back by one directory using cd, and they can also return to the parent directory using cd.
pwd Returns the information of the directory in which the user is located currently.

Conclusion

This article covered some of the basic differences between POSIX and UNIX, including some of the commands used in each. As can be seen from the above examples, there is no major difference between the commands used for POSIX and UNIX. POSIX is just a shell, whereas UNIX is a legacy OS.

]]> Is Linux POSIX-Compliant? https://linuxhint.com/is_linux_posix_compliant/ Wed, 13 Jan 2021 06:58:57 +0000 https://linuxhint.com/?p=85577

Software is written by numerous developers with various backgrounds. General algorithms are available under a free license or have been scientifically published, and they might also be available for free for studying purposes. This results in different implementations and software versions that fit a variety of needs. A standardization of interfaces and data formats is necessary to make these different implementations both interchangeable and modular.

In short, POSIX [1] does exactly that for UNIX and UNIX-like systems (see Zak H’s article [4] for a more detailed history on this topic). It defines the exchange interfaces, calling mechanisms, and transferred data for the software but leaves the internal implementation to the developer or maintainer of the software. The aim is to unify all the various UNIX forks and UNIX-like systems in such a way that different software implementations can interact with one another. The main advantage of POSIX is to have a binding documentation for these components – interfaces, mechanisms, and data – available in written form.

An operating system that follows the POSIX standard in its entirety is classified as being POSIX-compliant. In this article, we explain what POSIX stands for, determine whether Linux belongs to this category, and list which Linux components must be excluded from this classification.

What Does the Term POSIX Stand for?

POSIX is an abbreviation for Portable Operating System Interface. As briefly explained above, POSIX is the name for a collection of standards that are required to maintain compatibility between operating systems. As stated in [1], “[it] defines the application programming interface (API), along with command-line shells and utility interfaces, for software compatibility with variants of Unix and other operating systems.” The first version of POSIX was published in 1988. Since then, POSIX has been continuously expanded and updated by the Austin Common Standards Revision Group (also known simply as The Austin Group) [7].

As of 2021, the POSIX standard contains the following parts:

  1. Core Services (Incorporates Standard ANSI C) (IEEE std 1003.1-1988) – Process Creation and Control, Signals, File and Directory Operations, Pipes, C library, I/O Port Interface and Control, Process Triggers
  1. Extensions (Symbolic Links)
  2. Real-time and I/O extensions (IEEE Std 1003.1b-1993) – Priority Scheduling, Real-Time Signals, Clocks and Timers, Semaphores, Message Passing, Shared Memory, Asynchronous and Synchronous I/O, Memory Locking Interface
  3. Threads extensions (IEEE Std 1003.1c-1995) – Thread Creation, Control, and Clean-up, Thread Scheduling, Thread Synchronization, Signal Handling
  4. More real-time extensions
  5. Security extensions (Access control lists)
  1. Shell and Utilities (IEEE Std 1003.2-1992) –  Command Interpreter, Utility Programs

The standard is regularly reviewed to reflect technical changes and improvements. It can sometimes take several years before a new version is published and the changes are incorporated. This can be disadvantageous, but it is understandable given the scope of the standard.

In recent years, extensions to real-time processing have been added. The current version was released in early 2018 [3]. The authors of SibylFS [5] have also published many annotations to the POSIX standard to determine higher-order logic and interactions.

What Does Being POSIX-Compliant Mean?

The term “POSIX-compliant” means that an operating system meets all the POSIX criteria. An operating system can run UNIX programs natively, or an application can be ported from the UNIX system to another system. Porting an application from UNIX to the target operating system is easy, or at least easier, than if it does not support POSIX. To be on the safe side, an operating system should have successfully achieved the POSIX certification [2]. This step is achieved (at a cost) by passing an automated certification test. The corresponding test suite can be found here [11].

As of 2021, the list of POSIX-certified operating systems contains AIX from IBM, HP-UX from HP, IRIX from SGI, EulerOS [6] from Huawei, Mac OS X from Apple (since 10.5 Leopard), Solaris and QNX Neutrino from Oracle, Inspur’s K-UX [11], and the real-time OS INTEGRITY from Green Hills Software [15]. It is currently unclear whether newer versions of the three Solaris successors, OpenSolaris, Illumos, and OpenIndiana, are classified as fully POSIX-compliant, as well. These operating systems were POSIX-compliant until POSIX 2001.

Other operating systems that are seen as mostly (but not fully) POSIX-compliant include Android, BeOS, FreeBSD, Haiku, Linux (see below), and VMWare ESXi. For Microsoft Windows, Cygwin provides a largely POSIX-compliant development and run-time environment.

Is Linux POSIX-Compliant?

The term “Linux” refers to the entire Linux operating system, regardless of flavor, such as Debian GNU/Linux, RedHat Linux, Linux Mint, Ubuntu Linux, Fedora, and CentOS, for example. To be precise, Linux is just the name of the kernel that is the core component of this free operating system.

As Linus Torvalds described in the book “Just For Fun” [8], to develop the Linux kernel, he requested a copy of the POSIX standard. This helped him to implement the same mechanisms that are used in commercial UNIX systems. Furthermore, this allowed him to link the Linux kernel with the GNU tools that mainly followed the same approach. To be fair, the software on a Linux system is contributed from a variety of sources that respect the POSIX standard, but that also sometimes implement their own concepts. At the same time, however, this also shows the diversity that makes up Linux as an operating system.

One example of this is the way in which command-line arguments are written. Arguments with two dashes (e.g., “–help”) are GNU conventions, whereas POSIX commands never use two-dash arguments but instead only a single (e.g., “-help”). Right from the start, Linux was designed with GNU in mind, and that is why the commands contain GNU-style

arguments. To achieve POSIX compliance, POSIX-style arguments have been added step-by-step. Still, the final decision is made by the developer. As of today, most commands accept both short and long arguments, or even arguments without any dashes, such as the “find” command, for example. To be fair, there is no consistency between the commands on one system, and this can be a problem when you intend to use the same command on a different UNIX-based system, particularly when switching between Linux, OS X, and Solaris.

For now, Linux is not POSIX-certified due to high costs, except for the two commercial Linux distributions Inspur K-UX [12] and Huawei EulerOS [6]. Instead, Linux is seen as being mostly POSIX-compliant.

This assessment is due to the fact that major Linux distributions follow the Linux Standard Base (LSB) instead of POSIX [9]. LSB aims “to minimize the differences between individual Linux distributions” [14]. This refers to the software system structure, including the Filesystem Hierarchy Standard (FHS) used in the Linux kernel. LSB is based on the POSIX specification, the Single UNIX Specification (SUS) [10], and several other open standards, but also extends them in certain areas.

LSB-based Linux distributions include RedHat Linux, Debian GNU/Linux (2002-2015), and Ubuntu (until 2015), to name a few.

Developing with POSIX in mind

To understand POSIX in greater detail, we recommend obtaining a copy of the POSIX standard and reading it in full. You can get the book from the Open Group website. This requires a registration fee but gives you full access to this valuable resource. Standards help since they allow you to develop software in such a way that it behaves in the same way on all UNIX platforms.

Links and References

Thank You

The author would like to thank Axel Beckert and Veit Schiele for their help and advice while preparing this article.

]]> Posix Standard https://linuxhint.com/posix-standard/ Sun, 07 Jan 2018 06:40:19 +0000 https://linuxhint-com.zk153f8d-liquidwebsites.com/?p=21360

POSIX: An Overview

The Portable Operating System Interface (POSIX) is an IEEE standard that helps compatibility and portability between operating systems. Theoretically, POSIX compliant source code should be seamlessly portable. In the real world, application transition often runs into system specific issues. But POSIX compliance makes it simpler to port applications which can result in time savings. So developers should get acquainted with the fundamentals of this widely used standard.

History of POSIX

Early programmers had to rewrite their applications from scratch for each new computer model. But the IBM System/360 changed that. In 1964, it introduced the operating system OS/360. IBM started to use the same hardware architecture to enable the new models to reuse the same operating system. The presence of a common OS across multiple machines set up the first stage for application portability.

In the late 1960s, the arrival of UNIX opened up new possibilities. AT&T’s Bell Labs was responsible for the initial development of this new operating system. It could run across machines from multiple vendors. But UNIX started to fork into various flavors. Besides the AT&T’s System V, there were Berkeley Software Distribution (BSD), Xenix and more. It wasn’t easy to port across these flavors. The promise of application portability hit a road bump. In the coming decades, the introduction of new operating systems would only make it more complex to port applications across hardware, operating systems, and vendors.

POSIX standard was developed in the 1980s to resolve the portability issue. The standard was defined based on System V and BSD Unix. POSIX does not define the operating system, it only defines the interface between an application and an operating system. The programmers have the freedom to write their OS and application anyway they want as long as the interface between the two is honored. Because POSIX is independent of hardware, operating system or vendor, it’s easier to achieve application portability.

The first POSIX standard was released in 1988. Formally, it was called IEEE Standard 1003.1-1988 Portable Operating System Interface for Computer Environments”. In 1990, an international version of the same standard with slight variations was released as ISO/IEC 9945-1:1990 Information technology — Portable Operating System Interface (POSIX) — Part 1: System Application Program Interface (API).

Initially, POSIX was divided into multiple standards:

POSIX.1: Core Services
POSIX.1b: Real-time extensions
POSIX.1c: Threads extensions
POSIX.2: Shell and Utilities

After 1997, the Austin Group brought all the standard under a single umbrella. Since then, the versions POSIX.1-2001 (also known as IEEE Std 1003.1-2001), POSIX.1-2004 (also known as IEEE Std 1003.1-2004) and POSIX.1-2008 (also known as IEEE Std 1003.1-2008) have been released.

Examples of some POSIX-compliant systems are AIX, HP-UX, Solaris, and MacOS (since 10.5 Leopard). On the other hand, Android, FreeBSD, Linux Distributions, OpenBSD, VMWare, etc., follow most of the POSIX standard, but they are not certified.

Basics of POSIX

POSIX.1-2008 standard deals with four major areas:

  1. Base Definition Volume: General terms, concepts, and interfaces.
  2. Systems Interfaces Volume: Definitions of system service functions and subroutines. Also, includes portability, error handling and error recovery.
  3. Shell and Utilities Volume: Definition of interfaces of any application to command shells and common utility programs.
  4. Rationale Volume: Contains information and history about added or discarded features and the reasonings of the decisions.

The standard doesn’t cover graphical interfaces, database interfaces, object/binary code portability, system configurations, I/O considerations or resource availability.

Some of the guiding principles behind POSIX design are:

  • POSIX is created to make application portability easier. So it’s not for UNIX systems only. Non-UNIX systems can be POSIX-compliant too.
  • The standard doesn’t dictate the development of the application or the operating system. It only defines the contract between them.
  • POSIX-compliant application source code should be able to run across many systems because the standard is defined at the source code level. However, the standard doesn’t guarantee any object or binary code level portability. So the binary executable may not run even on similar machines with identical hardware and operating systems. Only source code portability is addressed in the standard.
  • POSIX is written in terms of Standard C. But developers can implement it in any language they like.
  • The standard only deals with aspects of the operating system that interacts with applications.
  • The standard is kept succinct in terms of length and broad in terms of scope to cover a large array of systems.
  • POSIX was designed to simplify portability. So it will save time and money in the long run. However, if your applications are not POSIX-compliant, it might require significant time and resource investment at the beginning.

POSIX Application Development

The purpose of POSIX was to improve portability. When your source code follows the standard, you can compile and run the code on a different machine easily. However, if POSIX is defined as a general requirement for an application, it can cause confusion. The full POSIX standard is 4000-plus pages with more than 1350 interfaces. It doesn’t make sense to implement everything. So each project should define the aspects of POSIX that will meet particular requirements.

There are misconceptions in the development community that POSIX standard is old and irrelevant. It is not true. POSIX is a living document that is being regularly updated by the Austin Group. Anyone can join the group and participate in improving the standard. The standard is used actively in today’s servers, workstations, routers, mobile devices, embedded systems and more. It is used for UNIX and Linux machines.

However, developers should be aware that POSIX standard has problems. You can report any bug you discover to the Austin Group and it will be looked into for the next revision.

Conclusion
POSIX might seem daunting at first. Still, application developers should get acquainted with the basics as it will pop up as a requirement from time to time. Due to the large scope of the standard, it’s not possible to become an expert on the full document. Developers can reach out to the UNIX and Linux communities to learn more. The communities can answer your questions and give you a better sense of what part of the standard will be relevant to your project.

Further Study:

References:

]]>