Technical Report (informative) Topic: Conflicts between ISO/IEC 9945 (POSIX) and the Linux Standard Base. Status: Unapproved Draft Author: Andrew Josey, The Open Group Version 1.3.0 Date: 20 August 2005 Change History: This version is updated to report against the the Linux Standard Base Core Specification 3.0. 001 1.Introduction 002 1.1 Purpose 003 The purpose of this Type 3 Technical Report (informative) is to document 004 the areas of conflict between ISO/IEC 9945 (POSIX) and the Free Standards 005 Group's Linux Standard Base specification such that it can be utilized 006 by the appropriate technical committees when considering harmonization 007 between the standards efforts. 008 ISO/IEC 9945 (POSIX) is an important standard in use throughout the world. 009 There is a significant investment in applications developed for the ISO 010 POSIX standard. With the emergence of a standardization initiative for 011 the Linux operating system there are some areas of conflict that have 012 been identified between the Linux Standard Base specification and the 013 ISO POSIX standards. There is an essential market requirement that the 014 conflicts be resolved so that an application can be written to conform 015 to both standards. Hundreds of millions of dollars of applications are 016 built upon these standards. This report is intended as a starting point 017 to look at resolution of this issue. 018 1.2 Scope 019 The JTC 1/SC 22 Linux Study Group meeting (May 2003) recommended future 020 action towards adopting a JTC1 standard for Linux, and most likely 021 adopting the Linux Standard Base (LSB) specification as a Publicly 022 Available Specification (PAS). The Free Standards Group has attained PAS 023 submitter status to JTC 1. The Free Standards Group has submitted the 024 LSB 2.0.1 specification for PAS approval. It is understood that the 025 Free Standards Group intends to submit a revised version of that 026 document in order to resolve comments received during the approval 027 process. The scope of this technical report is to identify 028 areas of conflict between the LSB 2.0 specification and the ISO/IEC 9945 029 (POSIX) standard. 030 This report is based on the Linux Standard Base Core Specification 031 3.0 , and ISO/IEC 9945:2003 edition dated 15th 032 August 2003 with ISO/IEC 9945:2003/Cor.1:2004 (published 15 Sep 2004). 033 1.3 Intended Audience 034 035 This document has been submitted to JTC1 as a Technical Report. 036 It is anticipated that they should distribute it to workgroups such 037 as the Austin Group and the Linux Standard Base for which it is in 038 scope. It is also intended to be of interest to systems engineers, 039 technical managers and procurement officers. 040 1.4 Document Overview 041 This document is organized in the following ways: Section two provides 042 a list of differences that could be possible conflicts or extensions in 043 the System Interfaces. Section three provides a list of differences that 044 could be possible conflicts or extensions in the Shell and Utilities. 045 1.5 Acknowledgements 046 Extracts of this document are quoted from the ISO/IEC 9945:2003 and 047 Linux Standard Base documents. 048 Thanks to Paul Eggert for detailed feedback on the Utility Interfaces 049 section of the document. 050 Linux is a registered trademark of Linus Torvalds. 051 LSB is a trademark of the Free Standards Group. 052 POSIX is a registered trademark of the IEEE. 053 2. General Observations 054 A notable change in the revised version of the LSB specification 055 post the PAS submission is that a new section has been introduced 056 "7. Relationship To ISO/IEC 9945 POSIX", in which it is stated that 057 "Any conflict between the requirements described here and the ISO POSIX 058 (2003) standard is unintentional, except as explicitly noted otherwise.". 059 3. System Interfaces 060 This section describes possible areas of conflict between the LSB and 061 ISO/IEC 9945 (POSIX) for the System Interfaces. 062 This description is based on the Linux Standard Base Core Specification 063 3.0. Note that the descriptions of the known conflicts are taken from 064 the LSB and have not been verified by the Austin Group, thus they may be 065 subject to interpretation of the standard. In some cases, the differences 066 may be upward compatible extensions. In cases where the LSB provides its 067 own API manual page rather than referencing ISO/IEC 9945 then that is 068 noted here and its possible that further investigation might determine 069 that there is no conflict. 070 3.1 Headers and Interface definitions 071 3.1.1 errno 072 LSB requires ENOTSUP to be defined the same as EOPNOTSUP, 073 whereas ISO/IEC 9945 requires that these errno values be unique. 074 A defect report has been filed to the Austin Group on this matter. 075 3.1.2 fcntl 076 LSB permits implementation to set O_LARGEFILE 077 According to ISO/IEC 9945, only an application sets fcntl() flags, 078 for example O_LARGEFILE. However, the LSB specification also 079 allows an implementation to set the O_LARGEFILE flag in the case 080 where the programming environment is one of _POSIX_V6_ILP32_OFFBIG, 081 _POSIX_V6_LP64_OFF64, _POSIX_V6_LPBIG_OFFBIG. See getconf and c99 in 082 ISO/IEC 9945 for a description of these environments. Thus, calling 083 fcntl() with the F_GETFL command may return O_LARGEFILE as well as flags 084 explicitly set by the application in the case that both the implementation 085 and the application support an off_t of at least 64 bits. 086 3.1.3 fscanf, fwscanf, scanf, vfscanf, vfwscanf, vscanf, vsscanf, vswscanf, 087 vwscanf, wscanf 088 The LSB states 089 The %s, %S and %[ conversion specifiers shall accept an option length modifier 090 a, which shall cause a memory buffer to be allocated to hold the string 091 converted. In such a case, the argument corresponding to the conversion 092 specifier should be a reference to a pointer value that will receive a pointer 093 to the allocated buffer. If there is insufficient memory to allocate a buffer, 094 the function may set errno to ENOMEM and a conversion error results. 095 According to the LSB this directly conflicts with the ISO C (1999) usage 096 of %a as a conversion specifier for hexadecimal float values. While this 097 conversion specifier should be supported, a format specifier such as 098 "%aseconds" will have a different meaning on an LSB conforming system. 099 3.1.4 getopt 100 The LSB documents a number of GNU extensions to getopt() as well as 101 descriptions of the POSIX requirements. Such extensions include argument 102 ordering. The LSB requires LSB implementations to implement the GNU 103 behavior. The POSIXLY_CORRECT environment variable is documented as a 104 method to obtain ISO/IEC 9945 conforming behavior. 105 3.1.5 kill 106 Process ID -1 doesn't affect calling process 107 If pid is specified as -1, LSB says that sig shall not be sent to the 108 calling process, whereas ISO/IEC 9945 states "If pid is -1, sig shall be 109 sent to all processes (excluding an unspecified set of system processes) 110 for which the process has permission to send that signal.". 111 This was a deliberate Linus decision after an unpopular experiment 112 in including the calling process in the 2.5.1 kernel. See "What does 113 it mean to signal everybody?", Linux Weekly News, 20 December 2001, 114 http://lwn.net/2001/1220/kernel.php3 115 3.1.6 link 116 link need not follow symbolic links 117 ISO/IEC 9945 specifies that pathname resolution shall follow symbolic 118 links during pathname resolution unless the function is required to act on the 119 symbolic link itself, or certain arguments direct that the function act on the 120 symbolic link itself. The ISO/IEC 9945 link() function contains no such 121 requirement to operate on a symbolic link. However, a conforming LSB 122 implementation need not follow a symbolic link for the path1 argument, 123 and hence may allow implementations of link() to create a link to 124 a symbolic link itself. 125 3.1.7 regexec 126 The LSB permits certain aspects of regular expression matching to be 127 optional; see Internationalization and Regular Expressions. 128 3.1.8 strerror_r 129 The Synopsis for strerror_r is defined in the LSB to have a return value 130 of type extern char * , whereas ISO/IEC 9945 defines the return value to 131 be type int. 132 Also according to the LSB it is optional whether an implementation 133 copies a message into the supplied buffer. 134 Returns String, not Error Value 135 The strerror_r() function shall return a pointer to the string 136 corresponding to errno. The returned pointer may point within the buffer 137 buf (at most buflen bytes). 138 Return Value 139 On success, strerror_r() shall return a pointer to the generated message 140 string (determined by the setting of the LC_MESSAGES category in the current 141 locale). Otherwise, strerror_r() shall return the string corresponding to 142 "Unknown error". 143 3.1.9 strptime 144 The LSB documents an issue with limiting the number of leading zeroes. 145 This may be a conflict and needs further investigation 146 as to the interpretation of ISO/IEC 9945 . 147 LSB states: 148 "Number of leading zeroes limited 149 The Single UNIX Specification, Version 2 specifies fields for which 150 "leading zeros are permitted but not required"; however, applications must 151 not expect to be able to supply more leading zeroes for these fields than 152 would be implied by the range of the field. Implementations may choose 153 to either match an input with excess leading zeroes, or treat this as 154 a non-matching input. For example, %j has a range of 001 to 366, so 0, 155 00, 000, 001, and 045 are acceptable inputs, but inputs such as 0000, 156 0366 and the like are not. 157 Rationale 158 glibc developers consider it appropriate behavior to forbid excess 159 leading zeroes. When trying to parse a given input against several format 160 strings, forbidding excess leading zeroes could be helpful. For example, 161 if one matches 0011-12-26 against %m-%d-%Y and then against %Y-%m-%d, 162 it seems useful for the first match to fail, as it would be perverse to 163 parse that date as November 12, year 26. The second pattern parses it 164 as December 26, year 11. 165 The Single UNIX Specification is not explicit that an unlimited 166 number of leading zeroes are required, although it may imply this. 167 The LSB explicitly allows implementations to have either behavior. 168 Future versions of this standard may require implementations to forbid 169 excess leading zeroes." 170 An Interpretation Request is currently pending against ISO/IEC 9945 for 171 this matter. 172 3.1.10 unlink 173 May return EISDIR on directories 174 The LSB states that if path specifies a directory, a return 175 of EISDIR is permitted instead of EPERM as required by ISO/IEC 9945. 176 LSB notes that "The Linux kernel has deliberately chosen EISDIR for this 177 case and does not expect to change (Al Viro, personal communication)." 178 3.1.11 waitpid 179 The LSB does not require implementations to support the 180 WCONTINUED or WIFCONTINUED functionality within waitpid(). 181 Its worth noting that these are XSI extensions (that is only 182 mandatory for UNIX systems, and so base POSIX conformance is 183 not impacted). 184 3.2 ISO/IEC 9945 system interfaces not in the LSB 185 It is believed that the LSB includes all the mandatory "base" 186 interfaces from ISO/IEC 9945. There are a number of optional 187 system interfaces from ISO/IEC 9945 that are not in the LSB. 188 Whilst not a direct conflict, a consequence of this is that 189 some applications written to ISO/IEC 9945 will not port to a strict 190 LSB implementation. It is recommended that development of a porting 191 guide be considered. 192 A number of known areas are noted below: 193 waitid 194 The LSB does not include the waitid() function, whereas it is a first 195 class function in ISO/IEC 9945 (but in the XSI option group). 196 The consequence of this is that an application written to conform to 197 ISO/IEC 9945 using waitid() does not conform to the LSB. 198 Realtime Threads and Advanced Realtime Thread Options 199 The LSB does not support functionality associated with the 200 Realtime options defined by ISO/IEC 9945 as the Realtime Threads, and 201 Advanced Realtime Threads Option Groups (see ISO/IEC 9945, 202 Base Definitions, section 2.1.5.2). Consequently any applications 203 using those features will not be LSB conforming. 204 This is documented within the LSB in the libpthread 205 section. 206 XSI STREAMS Option 207 The LSB does not support functionality associated with the 208 XSI STREAMS option defined by ISO/IEC 9945. 209 4. Shell and Utilities Interfaces 210 This section describes possible areas of conflict between the LSB and 211 ISO/IEC 9945 (POSIX) for the Shell and Utilities. 212 This description is based on the Linux Standard Base Core Specification 213 3.0. Note that the descriptions of the known conflicts are taken from 214 the LSB and have not been verified by the Austin Group, thus they may be 215 subject to interpretation of the standard. Deprecated differences are 216 not listed since they are assumed to be removed at some future point. 217 In some cases, the differences may be upward compatible extensions. In 218 cases where the LSB provides its own API manual page rather than 219 referencing ISO/IEC 9945 then that is noted here and its possible that 220 further investigation might determine that there is no conflict. 221 4.1 Built-in cd, getopts, read, umask and wait 222 ISO/IEC 9945 requires that a number of commands be provided 223 as built-in to the command language interpreter (as detailed 224 in XCU section 1.13) and also accesible via the exec family 225 of functions as defined in XSH and directly invocable 226 by standard utilities that require to invoke them 227 (env, find, nice, nohup, time and xargs). The LSB requires that the cd, 228 getopts, read, umask and wait utilities be built-in 229 to the command language interpreter and 230 forbids standard utilities from invoking them. 231 4.2 Utility definitions 232 4.2.1 ar 233 The ar utility is deprecated in the LSB. 234 4.2.2 at 235 The LSB lists the following differences: 236 -d is functionally equivalent to the -r option specified in ISO/IEC 9945 237 -r need not be supported on LSB implementations, but the '-d' option 238 is equivalent. 239 -t time 240 need not be supported. 241 The files at.allow and at.deny may reside in /etc rather than /usr/lib/cron 242 on LSB implementations. 243 4.2.3 awk 244 The LSB lists the following differences: 245 Certain aspects of internationalized regular expressions are optional. 246 4.2.4 batch 247 The LSB lists the following differences: 248 The files at.allow and at.deny may reside in /etc rather than /usr/lib/cron 249 on LSB implementations. 250 4.2.5 bc 251 In order to obtain ISO/IEC 9945 conforming behavior, applications 252 are required to use the -s or --standard option to bc. 253 The -w or --warn option can provide warnings for bc extensions being 254 used over the ISO/IEC 9945 definition. 255 4.2.6 chgrp 256 The -L, -H, and -P options need not be supported by LSB implementations. 257 ISO/IEC 9945 defines these options for manipulating symbolic 258 links. 259 4.2.7 chown 260 The -L, -H, and -P options need not be supported by LSB implementations. 261 ISO/IEC 9945 defines these options for manipulating symbolic 262 links. 263 4.2.8 crontab 264 The LSB lists the following differences: 265 The files at.allow and at.deny may reside in /etc rather than /usr/lib/cron 266 on LSB implementations. 267 4.2.9 cut 268 The LSB lists the following difference: 269 -n has unspecified behavior. 270 ISO/IEC 9945 defines the behavior of "-n" 271 Do not split characters. When specified with the -b option, each 272 element in list of the form low- high (hyphen-separated numbers) 273 shall be modified as follows: 274 * If the byte selected by low is not the first byte of a character, 275 low shall be decremented to select the first byte of the character 276 originally selected by low. If the byte selected by high is not 277 the last byte of a character, high shall be decremented to select 278 the last byte of the character prior to the character originally 279 selected by high, or zero if there is no prior character. If the 280 resulting range element has high equal to zero or low greater than 281 high, the list element shall be dropped from list for that input 282 line without causing an error. 283 Each element in list of the form low- shall be treated as above with 284 high set to the number of bytes in the current line, not including 285 the terminating . Each element in list of the form - high 286 shall be treated as above with low set to 1. Each element in list 287 of the form num (a single number) shall be treated as above with 288 low set to num and high set to num. 289 4.2.10 df 290 The LSB lists the following differences: 291 If the -k option is not specified, disk space is shown in unspecified 292 units. If the -P option is specified, the size of the unit shall be 293 printed on the header line in the format "%4s-blocks". Applications 294 should specify -k. 295 The XSI option -t has unspecified behavior. Applications should not 296 specify -t. 297 The LSB states that -t is used for a different purpose on a common 298 implementation. 299 Operand May Identify Special File 300 If an argument is the absolute file name of a special file containing a 301 mounted filesystem, df shall show the space available on that filesystem 302 rather than on the filesystem containing the special file (which is typically 303 the root filesystem). 304 The LSB states that in ISO/IEC 9945 the XSI optional behavior permits an 305 operand to name a special file, but appears to require the operation be 306 performed on the filesystem containing the special file. A defect report 307 has been submitted for this case. 308 4.2.11 du 309 The LSB lists the following differences: 310 If the -k option is not specified, disk space is shown in unspecified units. 311 Applications should specify -k. 312 4.2.12 echo 313 Unlike the behavior specified in ISO/IEC 9945, LSB states that support for 314 options is implementation defined, and that the behavior of echo if any 315 arguments contain backslashes is also implementation defined. Applications 316 are advised not to run echo with a first argument starting with a hyphen, 317 or with any arguments containing backslashes; they must use printf in 318 those cases. 319 The behavior specified here is similar to that specified by the Single UNIX 320 Specification version 3 without the XSI option. However, the LSB forbids all 321 options and ISO/IEC 9945 forbids only -n. 322 4.2.13 file 323 The LSB lists the following differences: 324 The -M, -h, -d, and -i options need not be supported. 325 4.2.14 find 326 The LSB lists the following differences: 327 Some elements of the Pattern Matching Notation are optional; see 328 Internationalization and Pattern Matching Notation. 329 -H 330 need not be supported 331 -L 332 need not be supported 333 -exec ... + 334 argument aggregation need not be supported 335 4.2.15 fuser 336 The LSB lists the following differences: 337 -c has unspecified behavior. 338 -f has unspecified behavior. 339 4.2.16 grep 340 The LSB lists the following differences: 341 Some elements of the Pattern Matching Notation are optional; see 342 Internationalization and Pattern Matching Notation. 343 4.2.17 ipcrm 344 The LSB states that if any of the -q, -Q, -s, -S, -m, or -M arguments 345 are given, the ipcrm shall behave as described in ISO/IEC 9945. 346 Otherwise, ipcrm shall remove the resource of the specified type identified by 347 id. 348 4.2.18 ipcs 349 The LSB has its own definition of ipcs and does not 350 reference ISO/IEC 9945. This definition is stated to contain 351 substantial differences from ISO/IEC 9945. 352 4.2.19 ls 353 For ls, the LSB only lists compatible extensions, no differences. 354 Where ISO/IEC 9945 states that there is 355 implementation defined behavior for -l on a special file, 356 the LSB defines that behavior; and the -p extension 357 is upwardly compatible. 358 4.2.20 more 359 The LSB lists these as differences, 360 The more command need not respect the LINES and COLUMNS environment 361 variables. 362 The more command need not support the following interactive commands: 363 g 364 G 365 u 366 control u 367 control f 368 newline 369 j 370 k 371 r 372 R 373 m 374 ' (return to mark) 375 /! 376 ? 377 N 378 :e 379 :t 380 control g 381 ZZ 382 -num 383 specifies an integer which is the screen size (in lines). 384 -e 385 has unspecified behavior. 386 -i 387 has unspecified behavior. 388 -n 389 has unspecified behavior. 390 -p 391 Either (1) clear the whole screen and then display the text (instead 392 of the usual scrolling behavior), or (2) provide the behavior 393 specified by ISO/IEC 9945. In the latter case, the syntax is 394 "-p command". 395 -t 396 has unspecified behavior. 397 4.2.21 newgrp 398 The LSB states that implementations need not support the -l 399 option as required in ISO/IEC 9945. 400 4.2.22 od 401 Pre-POSIX and XSI Specifications 402 The LSB supports mixing options between the mandatory and XSI optional 403 synopsis forms in ISO POSIX (2003). The LSB shall support the following 404 options: 405 -a 406 is equivalent to -t a, selects named characters. 407 -b 408 is equivalent to -t o1, selects octal bytes. 409 -c 410 is equivalent to -t c, selects characters. 411 -d 412 is equivalent to -t u2, selects unsigned decimal two byte units. 413 -f 414 is equivalent to -t fF, selects floats. 415 -i 416 is equivalent to -t d2, selects decimal two byte units. 417 -l 418 is equivalent to -t d4, selects decimal longs. 419 -o 420 is equivalent to -t o2, selects octal two byte units. 421 -x 422 is equivalent to -t x2, selects hexadecimal two byte units. 423 Note that the XSI option -s need not be supported. 424 4.2.23 renice 425 The LSB lists the following differences: 426 -n increment 427 has unspecified behavior. 428 4.2.24 sed 429 The LSB lists the following differences: 430 Certain aspects of internationalized regular expressions are optional 431 4.2.25 xargs 432 The LSB lists the following differences: 433 -E 434 has unspecified behavior. 435 -I 436 has unspecified behavior. 437 -L 438 has unspecified behavior. 439 4.3 Internationalization 440 The LSB makes certain internationalization aspects optional. 441 4.3.1 Regular Expressions 442 Utilities that process regular expressions shall support Basic Regular 443 Expressions and Extended Regular Expressions as specified in ISO/IEC 9945 444 with the following exceptions: 445 Range expression (such as [a-z]) can be based on code point order instead 446 of collating element order. 447 Equivalence class expression (such as [=a=]) and multi-character collating 448 element expression (such as [.ch.]) are optional. 449 Handling of a multi-character collating element is optional. 450 This affects at least the following utilities: grep, sed, and awk. 451 4.3.2 Pattern Matching Notation 452 Utilities that perform Pattern Matching Notation shall do it as specified 453 in ISO/IEC 9945 with the following exceptions: 454 Range expression (such as [a-z]) can be based on code point order instead 455 of collating element order. 456 Equivalence class expression (such as [=a=]) and multi-character collating 457 element expression (such as [.ch.]) are optional. 458 Handling of a multi-character collating element is optional. 459 4.4 ISO/IEC 9945 Utility interfaces not in the LSB 460 The LSB includes all the mandatory "base" utilities from ISO/IEC 9945. 461 There are a number of optional utility interfaces in ISO/IEC 9945 that 462 are not in the LSB. Whilst not a direct conflict, a consequence of this 463 is that some applications written to ISO/IEC 9945 will not port to a 464 strict LSB implementation. It is recommended that development of a 465 porting guide be considered. 466 A number of known areas are noted below: 467 Partial coverage of the User Portability Utilities option 468 The LSB does not require a full implementation of the 469 User Portability Utilities option, for example it does 470 require support for the at, batch, crontab, csplit, df, du, 471 expand, file, man, more, newgrp, nice, patch, ps, renice, split, 472 time, and unexpand. However, it omits support for alias, bg, 473 ctags, ex, fc, fg, jobs, mesg, nm, strings, tabs, talk, tput, 474 unalias, uudecode, uuencode, vi, who and write. 475 This is primarily since the LSB is targeted as a runtime environment 476 for applications rather than a user environment. 477 Development options 478 The LSB does not require implementations to support 479 the various development options with ISO/IEC 9945. 480 APPENDIX A 481 This appendix contains background information on the POSIX 482 Standards and the Linux Standard Base specification. 483 A1. POSIX Standards 484 The POSIX standards, are the foundations of the UNIX system and Linux 485 API sets. The development body for the POSIX standards has been 486 the IEEE in association with ISO/JTC1/SC22/WG15. 487 This section provides an overview of the POSIX standards. 488 A1.1 The Portable Application Standards Committee (PASC) 489 The IEEE Computer Society's Portable Application Standards Committee 490 (PASC) is the group that has and continues to develop the POSIX family 491 of standards. Historically, the major work has been undertaken within 492 Project 1003 (POSIX) with the best known standard being IEEE Std 1003.1 493 (also known as POSIX 1003.1, colloquially termed "dot 1"). The goal of 494 the PASC standards has been to promote application portability at the 495 source code level. 496 More Information about the Portable Application Standards Committee 497 (PASC) is available from: 498 http://www.pasc.org 499 A1.2 IEEE POSIX 1003.1 System Application Interface (C API) 500 Historically, this has been the base standard upon which the POSIX 501 family of standards has been built. In keeping with its original focus 502 on the UNIX system, it is aimed at interactive timesharing computing 503 environments. The latest version of this standard was produced by the 504 Austin Group (see later). In general the Linux operating system 505 aims to comply with the POSIX 1003.1 standard. 506 The first edition of IEEE Std 1003.1 was published in 1988. Subsequent 507 editions were published in 1990, 1996 and 2001. The 1990 edition was a 508 revision to the 1988 edition and became the stable base standard onto 509 which further amendments were added. The 1990 edition was also approved 510 as an international standard, ISO/IEC 9945-1:1990. 511 The 1996 edition added the IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995, 512 and 1003.1i-1995 amendments to the base standard, keeping the stable core 513 text unchanged. The 1996 edition of IEEE Std 1003.1 was also approved 514 as an international standard, ISO/IEC 9945-1:1996. 515 In 1998 the first real-time profile standard, IEEE Std 1003.13-1998 was 516 published, enabling POSIX to address embedded real-time applications 517 and smaller footprint devices. 518 In 1999 the decision was taken to commence the first major revision to 519 the core base standard in ten years, including a merger with the 1003.2 520 standards for Shell and Utilities which had been a separate standard 521 up to this point . It was agreed that this work be undertaken by the 522 Austin Group (see later ). As part of this decision the PASC decided 523 to cease rolling amendments to the base standard after completion of 524 IEEE Stds 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q, and 1003.2b. 525 These projects were rolled into the 2001 edition of IEEE Std 1003.1. 526 It was decided to convert other projects in progress to standalone 527 documents. 528 A1.3 IEEE POSIX 1003.2 Shell and Utilities 529 This standard defines a standard source level interface to the shell 530 and utility functionality required by application programs, including 531 shell scripts. This standard has been incorporated into the IEEE Std 532 1003.1-2001 produced by the Austin Group. The compliance level 533 of the Linux operating system is harder to determine for the 534 shell and utilities. 535 A1.4 IEEE POSIX Standards for Real-time 536 The PASC Real-time System Services Working Group (SSWG-RT) has developed 537 a series of standards that amend IEEE Std 1003.1-1990 and a profile 538 standard (IEEE Std 1003.13-1998). 539 The Real-time amendments to IEEE Std 1003.1-1990 are as follows: 540 IEEE Std 1003.1b-1993 Realtime Extension 541 IEEE Std 1003.1c-1995 Threads 542 IEEE Std 1003.1d-1999 Additional Realtime Extensions 543 IEEE Std 1003.1j-2000 Advanced Realtime Extensions 544 IEEE Std 1003.1q-2000 Tracing 545 These have all been folded in as options within the revision project 546 undertaken by the Austin Group (see below). 547 The Real-time profile is known as IEEE Std 1003.13-1998. At the time 548 of writing there is a revision to IEEE Std 1003.13-1998 in progress to 549 align it with IEEE Std 1003.1-2001, this project current known as IEEE 550 P1003.13-200x. 551 A1.5 The Austin Group 552 The Austin Group is the working group that manages the POSIX.1 553 specificaton. It is a joint working group of members of the IEEE Portable 554 Applications Standards Committee, members of The Open Group, and members 555 of ISO/IEC Joint Technical Committee 1. Participation is free and open 556 to all interested parties. 557 The Austin Group arose out of discussions amongst the parties which 558 started in early 1998, which led to an initial meeting and formation 559 of the group in September 1998. The purpose for this group has 560 been to revise, combine, and update the following standards: ISO/IEC 561 9945-1, ISO/IEC 9945-2, IEEE Std 1003.1, IEEE Std 1003.2, and the Base 562 Specifications of The Open Group Single UNIX Specification. 563 After two meetings, an agreement was signed in July 1999 between The 564 Open Group and the Institute of Electrical and Electronics Engineers 565 (IEEE), Inc., to formalize the project with the first draft of the 566 revised specifications ("the revision") being made available at the 567 same time. Under this agreement, The Open Group and IEEE agreed to share 568 joint copyright of the resulting work. 569 The base document for the revision was The Open Group's Base volumes 570 of its Single UNIX Specification, Version 2. These were selected since 571 they were a superset of the existing POSIX.1 and POSIX.2 specifications 572 and had some organizational aspects that would benefit the audience for 573 the new revision. 574 The approach to specification development has been one of "write once, 575 adopt everywhere", with the deliverables being a set of specifications 576 that carry the IEEE POSIX designation, The Open Group's Technical 577 Standard designation, and an ISO/IEC designation (see below). This set of 578 specifications also forms the core of the Single UNIX Specification, Version 3. 579 The Open Group and the IEEE approved the Austin Group specifications in 580 late 2001, as The Open Group Base Specifications, Issue 6, and IEEE Std 581 1003.1-2001 respectively. ISO/IEC approval followed about twelve 582 months later. 583 The Austin Group Specifications consist of the following : 584 * Base Definitions, Issue 6 (XBD) 585 * Shell and Utilities, Issue 6 (XCU) 586 * System Interfaces, Issue 6 (XSH) 587 * Rationale (Informative) 588 The revision has tried to minimize the number of changes that 589 implementations which conform to the earlier versions of the approved 590 standards would require to bring them into conformance with the current 591 standard. Specifically, the scope of the project excluded doing any 592 ``new'' work, but rather collecting into a single document what had 593 been spread across a number of documents, and presenting it in what 594 had been proven in practice to be a more effective way. Some changes 595 to prior conforming implementations were unavoidable, primarily as a 596 consequence of resolving conflicts found in prior revisions, or which 597 became apparent when bringing the various pieces together. Also, since 598 the revision now references the 1999 version of the ISO C standard, 599 there are a number of unavoidable changes that have been made which will 600 affect applications portability. 601 The 2004 edition of the 1003.1 standard was published on April 30th 602 2004, and updates the 2001 edition of the standard to include Technical 603 Corrigendum 1 (TC1) and Technical Corrigendum 2 (TC2). The 2004 Edition 604 is formally known as: 605 IEEE Std 1003.1, 2004 Edition 606 The Open Group Technical Standard Base Specifications, Issue 6 607 608 Includes IEEE Std 1003.1-2001, IEEE Std 1003.1-2001/Cor 1-2002 and 609 IEEE Std 1003.1-2001/Cor 2-2004 610 The second technical corrigendum (TC2) was published by 611 ISO/IEC as ISO/IEC 9945:2003/Cor-1:2004 on September 15 2004. 612 More information on the Austin Group, including how to join and 613 participate is available from its web site at 614 http://www.opengroup.org/austin/ 615 A html version of the specification is freely available from 616 The Open Group's Single UNIX Specification web site at 617 http://www.unix.org/version3/ 618 A1.5.1 Relationship to the ISO C Standard 619 The most recent revision to the ISO C standard occurred in 1999. 620 The ISO C standard is itself independent of any operating system in so 621 much as it may be implemented in many environments including 622 hosted environments. 623 The POSIX and Single UNIX Specification have a long history 624 of building on the ISO C standard and deferring to it where applicable. 625 Revisions of POSIX.1 prior to the Austin Group specification built upon 626 the ISO C standard by reference only, and also allowed support for traditional 627 C as an alternative. The Single UNIX Specification in contrast, 628 included manual pages for the ISO C interfaces. 629 The Austin Group took the latter approach. The standard 630 developers believed it essential for a programmer to have a single 631 complete reference place. They also recognized that deference to the formal 632 standard had to be addressed for the duplicate interface definitions 633 which occur in both the ISO C standard and their document. 634 It was agreed that where an interface has a version in the ISO C standard, 635 the DESCRIPTION section should describe the relationship to the ISO C 636 standard and markings added as appropriate within the manual page to 637 show where the ISO C standard has been extended. 638 A block of text was added to the start of each affected reference 639 page stating whether the page is aligned with the ISO C standard or 640 extended. Each page was parsed for additions beyond the ISO C standard 641 (that is, including both POSIX and UNIX extensions), and these extensions 642 are marked as CX extensions (for C Extensions). 643 A1.6 ISO/IEC 9945 644 In late 2002, the ISO/IEC Joint Technical Committee approved the joint 645 revision to POSIX and the Single UNIX Specification as an International 646 Standard. Designated as ISO/IEC 9945:2002, the joint revision forms 647 the core of The Open Group's Single UNIX Specification Version 3 (IEEE 648 1003.1-2001, POSIX.1). 649 The combining of the IEEE POSIX specifications and the Single UNIX 650 Specification into ISO/IEC 9945:2002 Parts 1 to 4 replaces the existing 651 ISO/IEC 9945-1:1996 (IEEE 1003.1, 1996 version), and ISO/IEC 9945-2:1993 652 (IEEE Std 1003.2, 1992 version). 653 ISO/IEC 9945 consists of the following parts, under the general title 654 Information technology Portable Operating System Interface (POSIX): 655 Part 1: Base Definitions 656 Part 2: System Interfaces 657 Part 3: Shell and Utilities 658 Part 4: Rationale 659 The 2003 Edition of the Austin Group specifications was published as 660 ISO/IEC 9945:2003 on August 15 2003. 661 The latest technical corrigendum is due to be published 662 shortly and is designated as ISO/IEC 9945:2003/Cor.1:2004. 663 A2.2 The Linux Standard Base Specification 664 The Linux Standard Base (LSB) Specification is an application binary 665 interface standard for shrink-wrapped applications. The purpose is to 666 allow commonality amongst the many Linux distributions. 667 The LSB draws on the source standards of IEEE POSIX 1003.1 and The Open 668 Group Single UNIX Specification for many of its interfaces although does 669 not formally defer to them preferring to document any differences where 670 they exist, such as where certain aspects of Linux cannot currently 671 conform to the industry standards, one particular example for early 672 versions of the LSB being the area of threads. Some interfaces are 673 not included in the LSB, since they are outside the remit of a binary 674 runtime environment, typically these are development interfaces or user 675 level tools . The LSB also extends the source standards in other areas 676 (such as graphics), and includes the necessary details such as the binary 677 execution file formats to support a high volume application platform. 678 Although in theory the LSB is not tied to the GNU/Linux operating system, 679 in practise the binary definitions are tightly coupled to the Linux operating 680 system and the GNU C compiler. 681 The LSB is available as a family of specifications supporting a 682 number of processor architectures including IA32, PPC32, PPC64, IA64, 683 S390 and S390X. There is a generic specification, common to all the 684 processor architectures known as the "generic LSB" (or gLSB), and for 685 each processor architecture an architecture-specific specification 686 ("archLSB") describing the details that vary by processor architecture. 687 To support the specification, the LSB includes a number of 688 development tools, including test suites, and a set of reference 689 conforming applications. Binary versions of the test suites and 690 reference applications are used for formal LSB certification of runtime 691 environments. All the major Linux vendors today have certified LSB 692 systems. 693 LSB 1.2, introduced in January 2002, was the first version of the 694 specification to have an equivalent LSB certification program. LSB 1.2 695 certification, which commenced in July 2002 is limited to the IA32 ABI. 696 LSB 1.3 certification includes additional support for the IA64, PPC32, 697 PPC64, S390 and S390X architectures. At the time of writing there are 698 thirty-eight certified runtime environments from 11 vendors. 699 The specification is evolving quite rapidly. LSB 1.3, introduced in 700 January 2003, adds some internationalization, PAM, packaging, static C++ 701 linking, bug fixes, plus IA64, PPC32, S390, and S390X. 702 LSB 2.0 was completed in August 2004, and adds some alignment 703 with ISO/IEC 9945:2003, support for 704 C++, and the additional architectures of AMD64 and PPC64. 705 LSB 2.0.1 was completed in October 2004, and was a minor revision. 706 This was the PAS submission to ISO. Since October 2004, the LSB 707 working group has been revising the specification, releasing 708 an LSB 2.1 specification during the first quarter 2005, releasing 709 the LSB 3.0 specification in the second quarter of 2005. 710 Detailed information on the LSB is available from: 711 http://www.linuxbase.org 712 713 Detailed information on the LSB Certification Program is available 714 from the LSB Certification Authority at 715 http://www.opengroup.org/lsb/cert/ 716 The Guide to LSB Certification is available at: 717 http://www.opengroup.org/lsb/cert/docs/LSB_Certification_Guide.html 718 The LSB Certification Register can be viewed at: 719 http://www.opengroup.org/lsb/cert/register.html