From owner-sc22docs@open-std.org Fri Oct 22 22:37:27 2004 Return-Path: X-Original-To: sc22docs-domo Delivered-To: sc22docs-domo@ghz.klid.dk Received: by ghz.klid.dk (Postfix, from userid 521) id A911737854; Fri, 22 Oct 2004 22:37:27 +0200 (CEST) X-Original-To: sc22info@open-std.org Delivered-To: sc22docs@ghz.klid.dk Received: from email1.ansi.org (outbound.ansi.org [12.15.192.5]) by ghz.klid.dk (Postfix) with ESMTP id 381003784C for ; Fri, 22 Oct 2004 22:37:22 +0200 (CEST) Received: by rpb2.nycrnybb.ispnetinc.net with Internet Mail Service (5.5.2653.19) id <4JX60B22>; Fri, 22 Oct 2004 16:36:19 -0400 Message-ID: From: Sally Seitz To: sc22info@open-std.org Subject: N 3823-ISO/IEC TR 34715-Technical Report on the Conflicts Between the ISO/IEC 9945 (POSIX) Standard and the Linux Standard Base Specificat ion (LSB) Date: Fri, 22 Oct 2004 16:36:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B876.C7A3F7C0" Sender: owner-sc22docs@open-std.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4B876.C7A3F7C0 Content-Type: text/plain ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N3823 TITLE: ISO/IEC TR 24715-Technical Report on the Conflicts between the ISO/IEC 9945 (POSIX) Standard and the Linux Standard Base Specification (LSB) DATE ASSIGNED: 2004-10-22 SOURCE: Project Editor (A. Josey) BACKWARD POINTER: DOCUMENT TYPE: DRAFT TR Text PROJECT NUMBER: STATUS: This document is issued per JeJu Resolution 04-16 which stated: "JTC 1SC 22 instructs the project editor for the Technical Report on conflicts between POSIX and LSB to make available a draft of the report based on LSB 2.0.1 before the commencement of the PAS Transposition Ballot on the LSB Core Document." The JTC 1 Secretariat has submitted the PAS documents to ITTF for ballot today, 2004-10-22. DUE DATE: DISTRIBUTION: TEXT ACTION ID: FYI CROSS REFERENCE: DISTRIBUTION FORM: Def Address reply to: ISO/IEC JTC 1/SC22 Secretariat Sally Seitz ANSI 25 West 43rd Street New York, NY 10036 Telephone: (212) 642-4918 Fax: (212) 840-2298 Email: sseitz@ansi.org __________________________________________End of cover page, beginning of document____________________________________ 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.2.4 Date: 21 October 2004 Change History: This version is updated to report against the Linux Standard Base Core Specification 2.0.1 (21 October 2004) 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 Linux as a JTC1 standard, 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 intend to submit the 024 LSB for PAS approval. The scope of this technical report is to identify 025 areas of conflict between the LSB 2.0 specification and the ISO/IEC 9945 026 (POSIX) standard. 027 This report is based on the Linux Standard Base Core Specification 2.0.1 028 dated October 2004, and ISO/IEC 9945:2003 edition dated 15th August 2003 029 with ISO/IEC 9945:2003/Cor.1:2004 (published 15 Sep 2004). 030 1.3 Intended Audience 031 032 This document is intended to be submitted to JTC1 as a Technical Report. 033 It is anticipated that they should distribute it to workgroups such 034 as the Austin Group and the Linux Standard Base for which it is in 035 scope. It is also intended to be of interest to systems engineers, 036 technical managers and procurement officers. 037 1.4 Document Overview 038 This document is organized in the following ways: Section two provides 039 a list of differences that could be possible conflicts or extensions in 040 the System Interfaces. Section three provides a list of differences that 041 could be possible conflicts or extensions in the Shell and Utilities. 042 1.5 Acknowledgements 043 Extracts of this document are quoted from the ISO/IEC 9945:2003 and 044 Linux Standard Base documents. 045 Thanks to Paul Eggert for detailed feedback on the Utility Interfaces 046 section of the document. 047 Linux is a registered trademark of Linus Torvalds. 048 LSB is a trademark of the Free Standards Group. 049 POSIX is a registered trademark of the IEEE. 050 2. System Interfaces 051 This section describes possible areas of conflict between the LSB and 052 ISO/IEC 9945 (POSIX) for the System Interfaces. 053 This description is based on the Linux Standard Base Core Specification 054 2.0.1. Note that the descriptions of the known conflicts are taken from 055 the LSB and have not been verified by the Austin Group, thus they may be 056 subject to interpretation of the standard. In some cases, the differences 057 may be upward compatible extensions. In cases where the LSB provides its 058 own API manual page rather than referencing ISO/IEC 9945 then that is 059 noted here and its possible that further investigation might determine 060 that there is no conflict. 061 2.1 Headers and Interface definitions 062 2.1.1 unistd.h 063 LSB requires _XOPEN_VERSION to be defined as 500, whereas 064 ISO/IEC 9945 (for systems supporting the XSI extension) requires 065 the symbolic constant to be defined as 600. 066 2.1.2 creat 067 LSB permits implementations to return ENODEV or ENXIO 068 for non-existent devices, whereas ISO/IEC 9945 requires ENXIO. 069 2.1.3 errno 070 LSB requires ENOTSUP to be defined the same as EOPNOTSUP, 071 whereas ISO/IEC 9945 requires that these errno values be unique. 072 2.1.4 fcntl 073 LSB permits implementation to set O_LARGEFILE 074 According to ISO/IEC 9945, only an application sets fcntl flags, such 075 as O_LARGEFILE. However, the LSB specification also allows implementations 076 to set O_LARGEFILE in a case in which the default behavior matches 077 the O_LARGEFILE behavior, for example off_t is 64 bits. The impact 078 is that applications when calling fcntl with the F_GETFL command may 079 receive the O_LARGEFILE flag set as well as the flags explicitly set by 080 the application. 081 2.1.5 fopen 082 LSB permits implementations to return ENODEV or ENXIO 083 for non-existent devices, whereas ISO/IEC 9945 requires ENXIO. 084 085 2.1.6 freopen 086 LSB permits implementations to return ENODEV or ENXIO 087 for non-existent devices, whereas ISO/IEC 9945 requires ENXIO. 088 2.1.7 getopt 089 The LSB documents a number of GNU extensions to getopt() as well as 090 descriptions of the POSIX requirements. Such extensions include argument 091 ordering. The LSB requires LSB implementations to implement the GNU 092 behavior. The POSIXLY_CORRECT environment variable is documented as a 093 method to obtain ISO/IEC 9945 conforming behavior. 094 2.1.8 ioctl 095 The LSB has its own definition of ioctl() and does not reference ISO/IEC 096 9945. The interface description says that applications shall not call 097 ioctl() unless as explicitly described in the LSB. The sockio man page 098 describes a set of socket ioctl() calls. 099 This would imply that an application that uses the ioctl() function 100 as described in ISO/IEC 9945 is not conforming to the LSB. Such an 101 application would be using the XSR option (XSI STREAMS option) within 102 ISO/IEC 9945. 103 2.1.9 kill 104 Process ID -1 doesn't affect calling process 105 If pid is specified as -1, LSB says that sig shall not be sent to the 106 calling process, whereas ISO/IEC 9945 states "If pid is -1, sig shall be 107 sent to all processes (excluding an unspecified set of system processes) 108 for which the process has permission to send that signal.". 109 This was a deliberate Linus decision after an unpopular experiment 110 in including the calling process in the 2.5.1 kernel. See "What does 111 it mean to signal everybody?", Linux Weekly News, 20 December 2001, 112 http://lwn.net/2001/1220/kernel.php3 113 2.1.10 open 114 LSB permits implementations to return ENODEV or ENXIO 115 for non-existent devices, whereas ISO/IEC 9945 requires ENXIO. 116 117 2.1.11 opterr, optind, optopt 118 The LSB has its own definition of opterr, optind and optopt and does not 119 reference ISO/IEC 9945. 120 2.1.12 strerror_r 121 The Synopsis for strerror_r is defined in the LSB to have a return value 122 of type extern char * , whereas ISO/IEC 9945 defines the return value to 123 be type int. 124 Also according to the LSB it is optional whether an implementation 125 copies a message into the supplied buffer. 126 2.1.13 strptime 127 The LSB documents an issue with limiting the number of leading zeroes. 128 This may be a conflict and needs further investigation 129 as to the interpretation of ISO/IEC 9945 . 130 LSB states: 131 "Number of leading zeroes limited 132 The Single UNIX Specification, Version 2 specifies fields for which 133 "leading zeros are permitted but not required"; however, applications must 134 not expect to be able to supply more leading zeroes for these fields than 135 would be implied by the range of the field. Implementations may choose 136 to either match an input with excess leading zeroes, or treat this as 137 a non-matching input. For example, %j has a range of 001 to 366, so 0, 138 00, 000, 001, and 045 are acceptable inputs, but inputs such as 0000, 139 0366 and the like are not. 140 Rationale 141 glibc developers consider it appropriate behavior to forbid excess 142 leading zeroes. When trying to parse a given input against several format 143 strings, forbidding excess leading zeroes could be helpful. For example, 144 if one matches 0011-12-26 against %m-%d-%Y and then against %Y-%m-%d, 145 it seems useful for the first match to fail, as it would be perverse to 146 parse that date as November 12, year 26. The second pattern parses it 147 as December 26, year 11. 148 The Single UNIX Specification is not explicit that an unlimited 149 number of leading zeroes are required, although it may imply this. 150 The LSB explicitly allows implementations to have either behavior. 151 Future versions of this standard may require implementations to forbid 152 excess leading zeroes." 153 2.1.14 unlink 154 May return EISDIR on directories 155 The LSB states that if path specifies a directory, a return 156 of EISDIR is permitted instead of EPERM as required by ISO/IEC 9945. 157 LSB notes that "The Linux kernel has deliberately chosen EISDIR for this 158 case and does not expect to change (Al Viro, personal communication)." 159 2.1.15 waitpid 160 The LSB does not require implementations to support the 161 WCONTINUED or WIFCONTINUED functionality within waitpid(). 162 2.2 ISO/IEC 9945 system interfaces not in the LSB 163 There are a number of system interfaces in ISO/IEC 9945 that are not in 164 the LSB. Whilst not a direct conflict, a consequence of this is that 165 some applications written to ISO/IEC 9945 will not port to a strict 166 LSB implementation. It is recommended that development of a porting 167 guide be considered. 168 A number of known areas are noted below: 169 waitid 170 The LSB does not include the waitid() function, whereas it is a first 171 class function in ISO/IEC 9945 (but in the XSI option group). 172 The consequence of this is that an application written to conform to 173 ISO/IEC 9945 using waitid() does not conform to the LSB. 174 Realtime Threads Options 175 The LSB does not support functionality associated with the 176 Realtime options defined by ISO/IEC 9945 as the Realtime Threads, and 177 Advanced Realtime Threads Option Groups (see ISO/IEC 9945, 178 Base Definitions, section 2.1.5.2). Consequently any applications 179 using those features will not be LSB conforming. 180 XSI STREAMS Option 181 The LSB does not support functionality associated with the 182 XSI STREAMS option defined by ISO/IEC 9945. 183 3. Shell and Utilities Interfaces 184 This section describes possible areas of conflict between the LSB and 185 ISO/IEC 9945 (POSIX) for the Shell and Utilities. 186 This description is based on the Linux Standard Base Core Specification 187 2.0.1. Note that the descriptions of the known conflicts are taken from 188 the LSB and have not been verified by the Austin Group, thus they may be 189 subject to interpretation of the standard. Deprecated differences are 190 not listed since they are assumed to be removed at some future point. 191 In some cases, the differences may be upward compatible extensions. In 192 cases where the LSB provides its own API manual page rather than 193 referencing ISO/IEC 9945 then that is noted here and its possible that 194 further investigation might determine that there is no conflict. 195 3.1 Utility definitions 196 3.1.1 ar 197 The ar utility is deprecated in the LSB. 198 3.1.2 at 199 The LSB lists the following differences: 200 -d is functionally equivalent to the -r option specified in ISO/IEC 9945 201 -r need not be supported on LSB implementations, but the '-d' option 202 is equivalent. 203 -t time 204 need not be supported. 205 The files at.allow and at.deny reside in /etc rather than /usr/lib/cron 206 on LSB implementations. 207 3.1.3 awk 208 The LSB lists the following differences: 209 Certain aspects of internationalized regular expressions are optional. 210 3.1.4 batch 211 The LSB lists the following differences: 212 The files at.allow and at.deny reside in /etc rather than /usr/lib/cron 213 on LSB implementations. 214 3.1.5 bc 215 In order to obtain ISO/IEC 9945 conforming behavior, applications 216 are required to use the -s or --standard option to bc. 217 The -w option can provide warnings for bc extensions being 218 used over the ISO/IEC 9945 definition. 219 3.1.6 chgrp 220 The -L, -H, and -P options need not be supported by LSB implementations. 221 ISO/IEC 9945 defines these options for manipulating symbolic 222 links. 223 3.1.7 chown 224 The -L, -H, and -P options need not be supported by LSB implementations. 225 ISO/IEC 9945 defines these options for manipulating symbolic 226 links. 227 3.1.8 crontab 228 The LSB lists the following differences: 229 The files at.allow and at.deny reside in /etc rather than /usr/lib/cron 230 on LSB implementations. 231 3.1.9 cut 232 The LSB lists the following difference: 233 -n has unspecified behavior. 234 ISO/IEC 9945 defines the behavior of "-n" 235 Do not split characters. When specified with the -b option, each 236 element in list of the form low- high (hyphen-separated numbers) 237 shall be modified as follows: 238 * If the byte selected by low is not the first byte of a character, 239 low shall be decremented to select the first byte of the character 240 originally selected by low. If the byte selected by high is not 241 the last byte of a character, high shall be decremented to select 242 the last byte of the character prior to the character originally 243 selected by high, or zero if there is no prior character. If the 244 resulting range element has high equal to zero or low greater than 245 high, the list element shall be dropped from list for that input 246 line without causing an error. 247 Each element in list of the form low- shall be treated as above with 248 high set to the number of bytes in the current line, not including 249 the terminating . Each element in list of the form - high 250 shall be treated as above with low set to 1. Each element in list 251 of the form num (a single number) shall be treated as above with 252 low set to num and high set to num. 253 3.1.10 df 254 The LSB lists the following differences: 255 If the -k option is not specified, disk space is shown in unspecified 256 units. Applications should specify -k. 257 If an argument is the absolute file name of a disk device node containing 258 a mounted filesystem, df shows the space available on that filesystem 259 rather than on the filesystem containing the device node (which is always 260 the root filesystem). 261 3.1.11 du 262 The LSB lists the following differences: 263 If the -k option is not specified, disk space is shown in unspecified units. 264 Applications should specify -k. 265 3.1.12 echo 266 Unlike the behavior specified in ISO/IEC 9945, LSB states that support for 267 options is implementation defined, and that the behavior of echo if any 268 arguments contain backslashes is also implementation defined. Applications 269 are advised not to run echo with a first argument starting with a hyphen, 270 or with any arguments containing backslashes; they must use printf in 271 those cases. 272 The behavior specified here is similar to that specified by the Single UNIX 273 Specification version 3 without the XSI option. However, the LSB forbids all 274 options and ISO/IEC 9945 forbids only -n. 275 3.1.13 file 276 The LSB lists the following differences: 277 The -M, -h, -d, and -i options need not be supported. 278 3.1.14 find 279 The LSB lists the following differences: 280 Some elements of the Pattern Matching Notation are optional; see 281 Internationalization and Pattern Matching Notation. 282 3.1.15 fuser 283 The LSB lists the following differences: 284 -c has unspecified behavior. 285 -f has unspecified behavior. 286 3.1.16 grep 287 The LSB lists the following differences: 288 Some elements of the Pattern Matching Notation are optional; see 289 Internationalization and Pattern Matching Notation. 290 3.1.17 ipcrm 291 The LSB states that if any of the -q, -Q, -s, -S, -m, or -M arguments 292 are given, the ipcrm shall behave as described in ISO/IEC 9945. 293 Otherwise, ipcrm shall remove the resource of the specified type identified by 294 id. 295 3.1.18 ipcs 296 The LSB has its own definition of ipcs and does not 297 reference ISO/IEC 9945. 298 3.1.19 ls 299 The LSB lists the following differences: 300 -l If the file is a character special or block special file, the size 301 of the file shall be replaced with two unsigned numbers in the format 302 "%u, %u", representing the major and minor device numbers associated 303 with the special file. 304 -p 305 in addition to the behavior of printing a slash for a directory, 306 ls -p may display other characters for other file types. 307 For the -p difference, since the ISO/IEC 9945 only defines the behavior 308 for directories this appears to be an upward compatible extension. 309 The LSB states that certain aspects of the pattern matching notation 310 are optional. 311 3.1.20 more 312 The LSB lists these as differences, 313 The more command need not respect the LINES and COLUMNS environment 314 variables. 315 The more command need not support the following interactive commands: 316 g 317 G 318 u 319 control u 320 control f 321 newline 322 j 323 k 324 r 325 R 326 m 327 ' (return to mark) 328 /! 329 ? 330 N 331 :e 332 :t 333 control g 334 ZZ 335 -num 336 specifies an integer which is the screen size (in lines). 337 -e 338 has unspecified behavior. 339 -i 340 has unspecified behavior. 341 -n 342 has unspecified behavior. 343 -p 344 Either (1) clear the whole screen and then display the text (instead 345 of the usual scrolling behavior), or (2) provide the behavior 346 specified by ISO/IEC 9945. In the latter case, the syntax is 347 "-p command". 348 -t 349 has unspecified behavior. 350 3.1.21 newgrp 351 The LSB states that implementations need not support the -l 352 option as required in ISO/IEC 9945. 353 3.1.22 od 354 The LSB lists these as differences. 355 -w, --width[=BYTES] 356 outputs BYTES bytes per output line. 357 --traditional 358 accepts arguments in pre-POSIX form described below 359 Pre-POSIX and XSI Specifications 360 The LSB supports option intermixtures with the following pre-POSIX 361 and XSI specifications: 362 -a 363 is equivalent to -t a, selects named characters. 364 -f 365 is equivalent to -t fF, selects floats. 366 -i 367 is equivalent to -t d2, selects decimal two byte units 368 -l 369 is equivalent to -t d4, selects decimal longs. 370 3.1.23 renice 371 The LSB lists the following differences: 372 -n increment 373 has unspecified behavior. 374 3.1.24 sed 375 The LSB lists the following differences: 376 Certain aspects of internationalized regular expressions are optional 377 3.1.25 xargs 378 The LSB lists the following differences: 379 -E 380 has unspecified behavior. 381 -I 382 has unspecified behavior. 383 -L 384 has unspecified behavior. 385 3.2 Internationalization 386 The LSB makes certain internationalization aspects optional. 387 3.2.1 Regular Expressions 388 Utilities that process regular expressions shall support Basic Regular 389 Expressions and Extended Regular Expressions as specified in ISO/IEC 9945 390 with the following exceptions: 391 Range expression (such as [a-z]) can be based on code point order instead 392 of collating element order. 393 Equivalence class expression (such as [=a=]) and multi-character collating 394 element expression (such as [.ch.]) are optional. 395 Handling of a multi-character collating element is optional. 396 This affects at least the following utilities: grep, sed, and awk. 397 3.2.2 Pattern Matching Notation 398 Utilities that perform Pattern Matching Notation shall do it as specified 399 in ISO/IEC 9945 with the following exceptions: 400 Range expression (such as [a-z]) can be based on code point order instead 401 of collating element order. 402 Equivalence class expression (such as [=a=]) and multi-character collating 403 element expression (such as [.ch.]) are optional. 404 Handling of a multi-character collating element is optional. 405 3.3 ISO/IEC 9945 Utility interfaces not in the LSB 406 There are a number of utility interfaces in ISO/IEC 9945 that are not in 407 the LSB. Whilst not a direct conflict, a consequence of this is that 408 some applications written to ISO/IEC 9945 will not port to a strict 409 LSB implementation. It is recommended that development of a porting 410 guide be considered. 411 A number of known areas are noted below: 412 Partial coverage of the User Portability Utilities option 413 The LSB does not require a full implementation of the 414 User Portability Utilities option, for example it does 415 require support for the at, batch, crontab, csplit, df, du, 416 expand, file, man, more, newgrp, nice, patch, ps, renice, split, 417 time, and unexpand. It omits support for alias, bg, 418 ctags, ex, fc, fg, jobs, mesg, nm, strings, tabs, talk, tput, 419 unalias, uudecode, uuencode, vi, who and write. 420 Development options 421 The LSB does not require implementations to support 422 the various development options with ISO/IEC 9945. 423 APPENDIX A 424 This appendix contains background information on the POSIX 425 Standards and the Linux Standard Base specification. 426 A1. POSIX Standards 427 The POSIX standards, are the foundations of the UNIX system and Linux 428 API sets. The development body for the POSIX standards has been 429 the IEEE in association with ISO/JTC1/SC22/WG15. 430 This section provides an overview of the POSIX standards. 431 A1.1 The Portable Application Standards Committee (PASC) 432 The IEEE Computer Society's Portable Application Standards Committee 433 (PASC) is the group that has and continues to develop the POSIX family 434 of standards. Historically, the major work has been undertaken within 435 Project 1003 (POSIX) with the best known standard being IEEE Std 1003.1 436 (also known as POSIX 1003.1, colloquially termed "dot 1"). The goal of 437 the PASC standards has been to promote application portability at the 438 source code level. 439 More Information about the Portable Application Standards Committee 440 (PASC) is available from: 441 http://www.pasc.org 442 A1.2 IEEE POSIX 1003.1 System Application Interface (C API) 443 Historically, this has been the base standard upon which the POSIX 444 family of standards has been built. In keeping with its original focus 445 on the UNIX system, it is aimed at interactive timesharing computing 446 environments. The latest version of this standard was produced by the 447 Austin Group (see later). In general the Linux operating system 448 aims to comply with the POSIX 1003.1 standard. 449 The first edition of IEEE Std 1003.1 was published in 1988. Subsequent 450 editions were published in 1990, 1996 and 2001. The 1990 edition was a 451 revision to the 1988 edition and became the stable base standard onto 452 which further amendments were added. The 1990 edition was also approved 453 as an international standard, ISO/IEC 9945-1:1990. 454 The 1996 edition added the IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995, 455 and 1003.1i-1995 amendments to the base standard, keeping the stable core 456 text unchanged. The 1996 edition of IEEE Std 1003.1 was also approved 457 as an international standard, ISO/IEC 9945-1:1996. 458 In 1998 the first real-time profile standard, IEEE Std 1003.13-1998 was 459 published, enabling POSIX to address embedded real-time applications 460 and smaller footprint devices. 461 In 1999 the decision was taken to commence the first major revision to 462 the core base standard in ten years, including a merger with the 1003.2 463 standards for Shell and Utilities which had been a separate standard 464 up to this point . It was agreed that this work be undertaken by the 465 Austin Group (see later ). As part of this decision the PASC decided 466 to cease rolling amendments to the base standard after completion of 467 IEEE Stds 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q, and 1003.2b. 468 These projects were rolled into the 2001 edition of IEEE Std 1003.1. 469 It was decided to convert other projects in progress to standalone 470 documents. 471 A1.3 IEEE POSIX 1003.2 Shell and Utilities 472 This standard defines a standard source level interface to the shell 473 and utility functionality required by application programs, including 474 shell scripts. This standard has been incorporated into the IEEE Std 475 1003.1-2001 produced by the Austin Group. The compliance level 476 of the Linux operating system is harder to determine for the 477 shell and utilities. 478 A1.4 IEEE POSIX Standards for Real-time 479 The PASC Real-time System Services Working Group (SSWG-RT) has developed 480 a series of standards that amend IEEE Std 1003.1-1990 and a profile 481 standard (IEEE Std 1003.13-1998). 482 The Real-time amendments to IEEE Std 1003.1-1990 are as follows: 483 IEEE Std 1003.1b-1993 Realtime Extension 484 IEEE Std 1003.1c-1995 Threads 485 IEEE Std 1003.1d-1999 Additional Realtime Extensions 486 IEEE Std 1003.1j-2000 Advanced Realtime Extensions 487 IEEE Std 1003.1q-2000 Tracing 488 These have all been folded in as options within the revision project 489 undertaken by the Austin Group (see below). 490 The Real-time profile is known as IEEE Std 1003.13-1998. At the time 491 of writing there is a revision to IEEE Std 1003.13-1998 in progress to 492 align it with IEEE Std 1003.1-2001, this project current known as IEEE 493 P1003.13-200x. 494 A1.5 The Austin Group 495 The Austin Group is the working group that manages the POSIX.1 496 specificaton. It is a joint working group of members of the IEEE Portable 497 Applications Standards Committee, members of The Open Group, and members 498 of ISO/IEC Joint Technical Committee 1. Participation is free and open 499 to all interested parties. 500 The Austin Group arose out of discussions amongst the parties which 501 started in early 1998, which led to an initial meeting and formation 502 of the group in September 1998. The purpose for this group has 503 been to revise, combine, and update the following standards: ISO/IEC 504 9945-1, ISO/IEC 9945-2, IEEE Std 1003.1, IEEE Std 1003.2, and the Base 505 Specifications of The Open Group Single UNIX Specification. 506 After two meetings, an agreement was signed in July 1999 between The 507 Open Group and the Institute of Electrical and Electronics Engineers 508 (IEEE), Inc., to formalize the project with the first draft of the 509 revised specifications ("the revision") being made available at the 510 same time. Under this agreement, The Open Group and IEEE agreed to share 511 joint copyright of the resulting work. 512 The base document for the revision was The Open Group's Base volumes 513 of its Single UNIX Specification, Version 2. These were selected since 514 they were a superset of the existing POSIX.1 and POSIX.2 specifications 515 and had some organizational aspects that would benefit the audience for 516 the new revision. 517 The approach to specification development has been one of "write once, 518 adopt everywhere", with the deliverables being a set of specifications 519 that carry the IEEE POSIX designation, The Open Group's Technical 520 Standard designation, and an ISO/IEC designation (see below). This set of 521 specifications also forms the core of the Single UNIX Specification, Version 3. 522 The Open Group and the IEEE approved the Austin Group specifications in 523 late 2001, as The Open Group Base Specifications, Issue 6, and IEEE Std 524 1003.1-2001 respectively. ISO/IEC approval followed about twelve 525 months later. 526 The Austin Group Specifications consist of the following : 527 * Base Definitions, Issue 6 (XBD) 528 * Shell and Utilities, Issue 6 (XCU) 529 * System Interfaces, Issue 6 (XSH) 530 * Rationale (Informative) 531 The revision has tried to minimize the number of changes that 532 implementations which conform to the earlier versions of the approved 533 standards would require to bring them into conformance with the current 534 standard. Specifically, the scope of the project excluded doing any 535 ``new'' work, but rather collecting into a single document what had 536 been spread across a number of documents, and presenting it in what 537 had been proven in practice to be a more effective way. Some changes 538 to prior conforming implementations were unavoidable, primarily as a 539 consequence of resolving conflicts found in prior revisions, or which 540 became apparent when bringing the various pieces together. Also, since 541 the revision now references the 1999 version of the ISO C standard, 542 there are a number of unavoidable changes that have been made which will 543 affect applications portability. 544 The 2004 edition of the 1003.1 standard was published on April 30th 545 2004, and updates the 2001 edition of the standard to include Technical 546 Corrigendum 1 (TC1) and Technical Corrigendum 2 (TC2). The 2004 Edition 547 is formally known as: 548 IEEE Std 1003.1, 2004 Edition 549 The Open Group Technical Standard Base Specifications, Issue 6 550 551 Includes IEEE Std 1003.1-2001, IEEE Std 1003.1-2001/Cor 1-2002 and 552 IEEE Std 1003.1-2001/Cor 2-2004 553 The second technical corrigendum (TC2) was published by 554 ISO/IEC as ISO/IEC 9945:2003/Cor-1:2004 on September 15 2004. 555 More information on the Austin Group, including how to join and 556 participate is available from its web site at 557 http://www.opengroup.org/austin/ 558 A html version of the specification is freely available from 559 The Open Group's Single UNIX Specification web site at 560 http://www.unix.org/version3/ 561 A1.5.1 Relationship to the ISO C Standard 562 The most recent revision to the ISO C standard occurred in 1999. 563 The ISO C standard is itself independent of any operating system in so 564 much as it may be implemented in many environments including 565 hosted environments. 566 The POSIX and Single UNIX Specification have a long history 567 of building on the ISO C standard and deferring to it where applicable. 568 Revisions of POSIX.1 prior to the Austin Group specification built upon 569 the ISO C standard by reference only, and also allowed support for traditional 570 C as an alternative. The Single UNIX Specification in contrast, 571 included manual pages for the ISO C interfaces. 572 The Austin Group took the latter approach. The standard 573 developers believed it essential for a programmer to have a single 574 complete reference place. They also recognized that deference to the formal 575 standard had to be addressed for the duplicate interface definitions 576 which occur in both the ISO C standard and their document. 577 It was agreed that where an interface has a version in the ISO C standard, 578 the DESCRIPTION section should describe the relationship to the ISO C 579 standard and markings added as appropriate within the manual page to 580 show where the ISO C standard has been extended. 581 A block of text was added to the start of each affected reference 582 page stating whether the page is aligned with the ISO C standard or 583 extended. Each page was parsed for additions beyond the ISO C standard 584 (that is, including both POSIX and UNIX extensions), and these extensions 585 are marked as CX extensions (for C Extensions). 586 A1.6 ISO/IEC 9945 587 In late 2002, the ISO/IEC Joint Technical Committee approved the joint 588 revision to POSIX and the Single UNIX Specification as an International 589 Standard. Designated as ISO/IEC 9945:2002, the joint revision forms 590 the core of The Open Group's Single UNIX Specification Version 3 (IEEE 591 1003.1-2001, POSIX.1). 592 The combining of the IEEE POSIX specifications and the Single UNIX 593 Specification into ISO/IEC 9945:2002 Parts 1 to 4 replaces the existing 594 ISO/IEC 9945-1:1996 (IEEE 1003.1, 1996 version), and ISO/IEC 9945-2:1993 595 (IEEE Std 1003.2, 1992 version). 596 ISO/IEC 9945 consists of the following parts, under the general title 597 Information technology Portable Operating System Interface (POSIX): 598 Part 1: Base Definitions 599 Part 2: System Interfaces 600 Part 3: Shell and Utilities 601 Part 4: Rationale 602 The 2003 Edition of the Austin Group specifications was published as 603 ISO/IEC 9945:2003 on August 15 2003. 604 The latest technical corrigendum is due to be published 605 shortly and is designated as ISO/IEC 9945:2003/Cor.1:2004. 606 A2.2 The Linux Standard Base Specification 607 The Linux Standard Base (LSB) Specification is an application binary 608 interface standard for shrink-wrapped applications. The purpose is to 609 allow commonality amongst the many Linux distributions. 610 The LSB draws on the source standards of IEEE POSIX 1003.1 and The Open 611 Group Single UNIX Specification for many of its interfaces although does 612 not formally defer to them preferring to document any differences where 613 they exist, such as where certain aspects of Linux cannot currently 614 conform to the industry standards, one particular example for early 615 versions of the LSB being the area of threads. Some interfaces are 616 not included in the LSB, since they are outside the remit of a binary 617 runtime environment, typically these are development interfaces or user 618 level tools . The LSB also extends the source standards in other areas 619 (such as graphics), and includes the necessary details such as the binary 620 execution file formats to support a high volume application platform. 621 Although in theory the LSB is not tied to the GNU/Linux operating system, 622 in practise the binary definitions are tightly coupled to the Linux operating 623 system and the GNU C compiler. 624 The LSB is available as a family of specifications supporting a 625 number of processor architectures including IA32, PPC32, PPC64, IA64, 626 S390 and S390X. There is a generic specification, common to all the 627 processor architectures known as the "generic LSB" (or gLSB), and for 628 each processor architecture an architecture-specific specification 629 ("archLSB") describing the details that vary by processor architecture. 630 To support the specification, the LSB includes a number of 631 development tools, including test suites, and a set of reference 632 conforming applications. Binary versions of the test suites and 633 reference applications are used for formal LSB certification of runtime 634 environments. All the major Linux vendors today have certified LSB 635 systems. 636 LSB 1.2, introduced in January 2002, was the first version of the 637 specification to have an equivalent LSB certification program. LSB 1.2 638 certification, which commenced in July 2002 is limited to the IA32 ABI. 639 LSB 1.3 certification includes additional support for the IA64, PPC32, 640 PPC64, S390 and S390X architectures. At the time of writing there are 641 thirty-eight certified runtime environments from 11 vendors. 642 The specification is evolving quite rapidly. LSB 1.3, introduced in 643 January 2003, adds some internationalization, PAM, packaging, static C++ 644 linking, bug fixes, plus IA64, PPC32, S390, and S390X. 645 LSB 2.0 was completed in August 2004, and adds some alignment 646 with ISO/IEC 9945:2003, support for 647 C++, and the additional architectures of AMD64 and PPC64. 648 LSB 2.0.1 was completed in October 2004, and is a minor revision 649 in preparation for the PAS submission to ISO. 650 Detailed information on the LSB is available from: 651 http://www.linuxbase.org 652 653 Detailed information on the LSB Certification Program is available 654 from the LSB Certification Authority at 655 http://www.opengroup.org/lsb/cert/ 656 The Guide to LSB Certification is available at: 657 http://www.opengroup.org/lsb/cert/docs/LSB_Certification_Guide.html 658 The LSB Certification Register can be viewed at: 659 http://www.opengroup.org/lsb/cert/register.html Sally Seitz Program Administrator ANSI 25 West 43rd Street New York, NY 10036 Phone: (212) 642-4918 Fax: (212) 840-2298 ------_=_NextPart_001_01C4B876.C7A3F7C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

ISO/IEC JTC = 1/SC22

Programming languages, their environments = and system software interfaces

Secretariat:  U.S.A.  = (ANSI)

 

ISO/IEC JTC 1/SC22 = N3823

 

TITLE: ISO/IEC TR 24715-Technical Report on = the Conflicts between the ISO/IEC 9945 (POSIX) Standard and the Linux Standard Base Specification (LSB)

 

DATE ASSIGNED:

2004-10-22

 

SOURCE:

Project Editor (A. = Josey)

 

BACKWARD = POINTER:

 

DOCUMENT TYPE:

DRAFT TR Text

 

PROJECT NUMBER:

 

STATUS:

This document is issued per JeJu Resolution = 04-16 which stated: "JTC 1SC 22 instructs the project editor for the = Technical Report on conflicts between POSIX and LSB to make available a draft of = the report based on LSB 2.0.1 before the commencement of the PAS = Transposition Ballot on the LSB Core Document."  The JTC 1 Secretariat has = submitted the PAS documents to ITTF for ballot today, 2004-10-22. =

DUE DATE:

 

DISTRIBUTION:

TEXT

 

ACTION ID:

FYI

 

CROSS = REFERENCE:

 

DISTRIBUTION = FORM:

Def

 

Address reply = to:

ISO/IEC JTC 1/SC22 = Secretariat

Sally = Seitz

ANSI

25 West 43rd = Street

New York, NY  10036

Telephone:  (212) = 642-4918

Fax:          &n= bsp;  (212) 840-2298

Email:  sseitz@ansi.org

__________________________________________End of cover page, beginning of = document____________________________________

 

 

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.2.4

 

Date: 21 October = 2004

 

 

Change History:

This version is updated to report against = the Linux Standard Base

Core Specification 2.0.1 (21 October = 2004)

 

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 Linux as a JTC1 standard, 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 intend to submit the

024 LSB for PAS approval.  The scope of = this technical report is to identify

025 areas of conflict between the LSB 2.0 specification and the ISO/IEC 9945

026 (POSIX) = standard.

    =

 

027 This report is based on the Linux = Standard Base Core Specification 2.0.1

028 dated October 2004, and ISO/IEC = 9945:2003 edition dated 15th August 2003

029 with ISO/IEC 9945:2003/Cor.1:2004 = (published 15 Sep 2004).

    =

 

030 1.3 Intended = Audience

031          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;         

032 This document is intended to be = submitted to JTC1 as a Technical Report.

033 It is anticipated that they should = distribute it to workgroups such

034 as the Austin Group and the Linux = Standard Base for which it is in

035 scope. It is also intended to be of = interest to systems engineers,

036 technical managers and procurement = officers.

    =

 

037 1.4 Document = Overview

    =

 

    =

 

038 This document is organized in the = following ways: Section two provides

039 a list of differences that could be = possible conflicts or extensions in

040 the System Interfaces. Section three = provides a list of differences that

041 could be possible conflicts or = extensions in the Shell and Utilities.

    =

 

042 1.5 = Acknowledgements

    =

 

043 Extracts of this document are quoted = from the ISO/IEC 9945:2003 and

044 Linux Standard Base documents. =

    =

 

045 Thanks to Paul Eggert for detailed = feedback on the Utility Interfaces

046 section of the = document.

    =

 

047 Linux is a registered trademark of Linus Torvalds.

048 LSB is a trademark of the Free Standards = Group.

049 POSIX is a registered trademark of the = IEEE.

    =

 

050 2. System = Interfaces

    =

 

051 This section describes possible areas of conflict between the LSB and

052 ISO/IEC 9945 (POSIX) for the System = Interfaces.

    =

 

053 This description is based on the Linux = Standard Base Core Specification

054 2.0.1.  Note that the descriptions = of the known conflicts are taken from

055 the LSB and have not been verified by = the Austin Group, thus they may be

056 subject to interpretation of the = standard. In some cases, the differences

057 may be upward compatible extensions. In = cases where the LSB provides its

058 own API manual page rather than = referencing ISO/IEC 9945 then that is

059 noted here and its possible that further investigation might determine

060 that there is no = conflict.

    =

 

    =

 

061 2.1 Headers and Interface = definitions

    =

 

062 2.1.1 = unistd.h

    =

 

063 LSB requires _XOPEN_VERSION to be = defined as 500, whereas

064 ISO/IEC 9945 (for systems supporting the = XSI extension) requires

065 the symbolic constant to be defined as = 600.

    =

 

066 2.1.2 creat

    =

 

067 LSB permits implementations to return = ENODEV or ENXIO

068 for non-existent devices, whereas = ISO/IEC 9945 requires ENXIO.

    =

 

069 2.1.3 errno

    =

 

070 LSB requires ENOTSUP to be defined the = same as EOPNOTSUP,

071 whereas ISO/IEC 9945 requires that these = errno values be unique.

    =

 

072 2.1.4 fcntl

    =

 

073 LSB permits implementation to set = O_LARGEFILE

    =

 

074 According to ISO/IEC 9945, only an = application sets fcntl flags, such

075 as O_LARGEFILE. However, the LSB = specification also allows implementations

076 to set O_LARGEFILE in a case in which = the default behavior matches

077 the O_LARGEFILE behavior, for example = off_t is 64 bits.  The impact

078 is that applications  when calling = fcntl with the F_GETFL command may

079 receive the O_LARGEFILE flag set as well = as the flags explicitly set by

080 the = application.

    =

 

081 2.1.5 fopen

    =

 

082 LSB permits implementations to return = ENODEV or ENXIO

083 for non-existent devices, whereas = ISO/IEC 9945 requires ENXIO.

084 

085 2.1.6 = freopen

    =

 

086 LSB permits implementations to return = ENODEV or ENXIO

087 for non-existent devices, whereas = ISO/IEC 9945 requires ENXIO.

    =

 

088 2.1.7 = getopt

    =

 

089 The LSB documents a number of GNU = extensions to getopt() as well as

090 descriptions of the POSIX requirements. = Such extensions include argument

091 ordering. The LSB requires LSB = implementations to implement the GNU

092 behavior.  The POSIXLY_CORRECT = environment variable is documented as a

093 method to obtain ISO/IEC 9945 conforming behavior.

    =

 

    =

 

094 2.1.8 ioctl

    =

 

095 The LSB has its own definition of = ioctl() and does not reference ISO/IEC

096 9945.  The interface description = says that applications shall not call

097 ioctl() unless as explicitly described = in the LSB. The sockio man page

098 describes a set of socket ioctl() = calls.

    =

 

099 This would imply that an application = that uses the ioctl() function

100 as described in ISO/IEC 9945 is not = conforming to the LSB. Such an

101 application would be using the XSR = option (XSI STREAMS option) within

102 ISO/IEC = 9945.

    =

 

103 2.1.9 kill

    =

 

104 Process ID -1 doesn't affect calling = process

    =

 

105 If pid is specified as -1, LSB says that = sig shall not be sent to the

106 calling process, whereas ISO/IEC 9945 = states "If pid is -1, sig shall be

107 sent to all processes (excluding an = unspecified set of system processes)

108 for which the process has permission to = send that signal.".

    =

 

109 This was a deliberate Linus decision = after an unpopular experiment

110 in including the calling process in the = 2.5.1 kernel. See "What does

111 it mean to signal everybody?", = Linux Weekly News, 20 December 2001,

112 = http://lwn.net/2001/1220/kernel.php3

    =

 

113 2.1.10 open

    =

 

114 LSB permits implementations to return = ENODEV or ENXIO

115 for non-existent devices, whereas = ISO/IEC 9945 requires ENXIO.

116 

117 2.1.11 opterr, optind, = optopt

    =

 

118 The LSB has its own definition of = opterr, optind and optopt and does not

119 reference ISO/IEC = 9945.

    =

 

120 2.1.12 = strerror_r

    =

 

121 The Synopsis for strerror_r is defined = in the LSB to have a return  value

122 of type extern char * , whereas ISO/IEC = 9945 defines the return value to

123 be type = int.

    =

 

124 Also according to the LSB it is optional = whether an implementation

125 copies a message into the supplied = buffer.

    =

 

126 2.1.13 = strptime

    =

 

127 The LSB documents an issue with limiting = the number of leading zeroes.

128 This may be a conflict and needs further investigation

129 as to the interpretation of ISO/IEC 9945 = .

    =

 

130 LSB states:

    =

 

131 "Number of leading zeroes = limited

    =

 

132 The Single UNIX Specification, Version 2 specifies fields for which

133 "leading zeros are permitted but = not required"; however, applications must

134 not expect to be able to supply more = leading zeroes for these fields than

135 would be implied by the range of the = field. Implementations may choose

136 to either match an input with excess = leading zeroes, or treat this as

137 a non-matching input. For example, %j = has a range of 001 to 366, so 0,

138 00, 000, 001, and 045 are acceptable = inputs, but inputs such as 0000,

139 0366 and the like are = not.

    =

 

140 Rationale

    =

 

141 glibc developers consider it appropriate behavior to forbid excess

142 leading zeroes. When trying to parse a = given input against several format

143 strings, forbidding excess leading = zeroes could be helpful. For example,

144 if one matches 0011-12-26 against = %m-%d-%Y and then against %Y-%m-%d,

145 it seems useful for the first match to = fail, as it would be perverse to

146 parse that date as November 12, year 26. = The second pattern parses it

147 as December 26, year = 11.

    =

 

148 The Single UNIX Specification is not = explicit that an unlimited

149 number of leading zeroes are required, = although it may imply this.

150 The LSB explicitly allows = implementations to have either behavior.

151 Future versions of this standard may = require implementations to forbid

152 excess leading = zeroes."

    =

 

    =

 

153 2.1.14 = unlink

    =

 

154 May return EISDIR on = directories

    =

 

155 The LSB states that if path specifies a directory, a return

156 of EISDIR is permitted instead of EPERM = as required by ISO/IEC 9945.

    =

 

157 LSB notes that "The Linux kernel = has deliberately chosen EISDIR for this

158 case and does not expect to change (Al = Viro, personal communication)."

    =

 

    =

 

159 2.1.15 = waitpid

    =

 

160 The LSB does not require implementations = to support the

161 WCONTINUED or WIFCONTINUED functionality = within waitpid().

    =

 

162 2.2 ISO/IEC 9945 system interfaces not = in the LSB

    =

 

163 There are a number of system interfaces = in ISO/IEC 9945 that are not in

164 the LSB. Whilst not a direct conflict, a consequence of this is that

165 some applications written to ISO/IEC = 9945  will not port to a strict

166 LSB implementation.  It is = recommended that  development of a porting

167 guide be considered.

    =

 

168 A number of known areas are noted = below:

    =

 

169 waitid

    =

 

170 The LSB does not include the waitid() = function, whereas it is a first

171 class function in ISO/IEC 9945 (but in = the XSI option group).

172 The consequence of this is that an = application written to conform to

173 ISO/IEC 9945 using waitid() does not = conform to the LSB.

    =

 

174 Realtime Threads = Options

    =

 

175 The LSB does not support functionality associated with the

176 Realtime options defined by ISO/IEC 9945 = as the Realtime Threads, and

177 Advanced Realtime Threads Option Groups = (see ISO/IEC 9945,

178 Base Definitions, section 2.1.5.2). = Consequently any applications

179 using those features will not be LSB = conforming.

    =

 

180 XSI STREAMS = Option

    =

 

181 The LSB does not support functionality associated with the

182 XSI STREAMS option defined by ISO/IEC = 9945.

    =

 

    =

 

183 3. Shell and Utilities = Interfaces

    =

 

184 This section describes possible areas of conflict between the LSB and

185 ISO/IEC 9945 (POSIX) for the Shell and Utilities.

    =

 

186 This description is based on the Linux = Standard Base Core Specification

187 2.0.1.  Note that the descriptions = of the known conflicts are taken from

188 the LSB and have not been verified by = the Austin Group, thus they may be

189 subject to interpretation of the = standard. Deprecated differences are

190 not listed since they are assumed to be = removed at some future point.

191 In some cases, the differences may be = upward compatible extensions. In

192 cases where the LSB provides its own API = manual page rather than

193 referencing ISO/IEC 9945 then that is = noted here and its possible that

194 further investigation might determine = that there is no conflict.

    =

 

    =

 

195 3.1 Utility = definitions

    =

 

196 3.1.1 ar

    =

 

197 The ar utility is deprecated in the = LSB.

  =   

 

198 3.1.2 at

    =

 

199 The LSB lists the following = differences:

    =

 

200 -d is functionally equivalent to the -r o= ption specified in ISO/IEC 9945

    =

 

201 -r need not be supported on LSB = implementations, but the '-d' option

202    is = equivalent.

    =

 

203 -t time

204    need not be = supported.

    =

 

205 The files at.allow and at.deny reside in = /etc rather than /usr/lib/cron

206 on LSB = implementations.

    =

 

207 3.1.3  = awk

    =

 

208 The LSB lists the following = differences:

    =

 

209 Certain aspects of internationalized = regular expressions are optional.

    =

 

210 3.1.4 batch

    =

 

211 The LSB lists the following = differences:

    =

 

212 The files at.allow and at.deny reside in = /etc rather than /usr/lib/cron

213 on LSB = implementations.

    =

 

214 3.1.5  = bc

    =

 

215 In order to obtain ISO/IEC 9945 = conforming behavior, applications

216 are required to use the -s or --standard = option to bc.

217 The -w option can provide warnings for = bc extensions being

218 used over the ISO/IEC 9945 = definition.

    =

 

219 3.1.6 chgrp

    =

 

220 The -L, -H, and -P options need not be = supported by LSB implementations.

221 ISO/IEC 9945 defines these options for manipulating symbolic

222 links.

    =

 

223 3.1.7  = chown

    =

 

224 The -L, -H, and -P options need not be = supported by LSB implementations.

225 ISO/IEC 9945 defines these options for manipulating symbolic

226 links.

    =

 

227 3.1.8 = crontab

    =

 

228 The LSB lists the following = differences:

    =

 

229 The files at.allow and at.deny reside in = /etc rather than /usr/lib/cron

230 on LSB = implementations.

    =

 

231 3.1.9  = cut

    =

 

232 The LSB lists the following = difference:

    =

 

233 -n has unspecified = behavior.

    =

 

234 ISO/IEC 9945 defines the behavior of "-n"

    =

 

235     Do not split = characters. When specified with the -b option, each

236     element in list = of the form low- high (hyphen-separated numbers)

237     shall be = modified as follows:

    =

 

238     * If the byte = selected by low is not the first byte of a character,

239       low = shall be decremented to select the first byte of the character

240       = originally selected by low. If the byte selected by high is not

241       the = last byte of a character, high shall be decremented to select

242       the = last byte of the character prior to the character originally

243       = selected by high, or zero if there is no prior character. If the

244       = resulting range element has high equal to zero or low greater than

245       = high, the list element shall be dropped from list for that input

246       line = without causing an error.

    =

 

247     Each element in = list of the form low- shall be treated as above with

248     high set to the = number of bytes in the current line, not including

249     the terminating = <newline>. Each element in list of the form - high

250     shall be treated = as above with low set to 1. Each element in list

251     of the form num = (a single number) shall be treated as above with

252     low set to num = and high set to num.

    =

 

253 3.1.10 df

    =

 

254 The LSB lists the following = differences:

    =

 

255 If the -k option is not specified, disk = space is shown in unspecified

256 units. Applications should specify = -k.

    <= /p>

 

257 If an argument is the absolute file name = of a disk device node containing

258 a mounted filesystem, df shows the space available on that filesystem

259 rather than on the filesystem containing = the device node (which is always

260 the root = filesystem).

    =

 

261 3.1.11 du

    =

 

262 The LSB lists the following = differences:

    =

 

263 If the -k option is not specified, disk = space is shown in unspecified units.

264 Applications should specify = -k.

    =

 

265 3.1.12 echo

    =

 

266 Unlike the behavior specified in ISO/IEC = 9945, LSB states that support for

267 options is implementation defined, and = that the behavior of echo if any

268 arguments contain backslashes is also implementation defined. Applications

269 are advised not  to run echo with a = first argument starting with a hyphen,

270 or with any arguments containing = backslashes; they must use printf in

271 those = cases.

    =

 

272 The behavior specified here is similar = to that specified by the Single UNIX

273 Specification version 3 without the XSI = option. However, the LSB forbids all

274 options and ISO/IEC 9945 forbids only = -n.

    =

 

275 3.1.13 file

    =

 

276 The LSB lists the following = differences:

    =

 

277 The -M, -h, -d, and -i options need not = be supported.

    =

 

278 3.1.14 find

    =

 

279 The LSB lists the following = differences:

    =

 

280 Some elements of the Pattern Matching = Notation are optional; see

281 Internationalization and Pattern = Matching Notation.

    =

 

282 3.1.15 = fuser

    =

 

283 The LSB lists the following = differences:

    =

 

284 -c has unspecified = behavior.

    =

 

285 -f has unspecified = behavior.

    =

 

286 3.1.16 grep

    =

 

287 The LSB lists the following = differences:

    =

 

288 Some elements of the Pattern Matching = Notation are optional; see

289 Internationalization and Pattern = Matching Notation.

    =

 

290 3.1.17 = ipcrm

    =

 

291 The LSB states that if any of the -q, = -Q, -s, -S, -m, or -M arguments

292 are given, the ipcrm shall behave as = described in ISO/IEC 9945.

    =

 

293 Otherwise, ipcrm shall remove the = resource of the specified type identified by

294 id.

    =

 

295 3.1.18 ipcs

    =

 

296 The LSB has its own definition of ipcs = and does not

297 reference ISO/IEC = 9945.

    =

 

298 3.1.19 ls

    =

 

299 The LSB lists the following = differences:

    =

 

300 -l If the file is a character special or = block special file, the size

301 of the file shall be replaced with two = unsigned numbers in the format

302 "%u, %u", representing the = major and minor device numbers associated

303 with the special = file.

    =

 

304 -p

305      in = addition to the behavior of printing a slash for a directory,

306      ls -p may = display other characters for other file types.

    =

 

307 For the -p difference, since the ISO/IEC = 9945 only defines the behavior

308 for directories this appears to be an = upward compatible extension.

    =

 

309 The LSB states that certain aspects of = the pattern matching notation

310 are = optional.

    =

 

311 3.1.20 more

    =

 

312 The LSB lists these as = differences,

    =

 

313 The more command need not respect the = LINES and COLUMNS environment

314 variables.

    =

 

315 The more command need not support the = following interactive commands:

    =

 

316  g

317  G

318  u

319  control = u

320  control = f

321  = newline

322  j

323  k

324  r

325  R

326  m

327  ' (return to = mark)

328  = /!

329  = ?

330  = N

331  = :e

332  = :t

333  control = g

334  = ZZ

    =

 

335 -num

336      specifies = an integer which is the screen size (in lines).

    =

 

337 -e

338      has = unspecified behavior.

    =

 

339 -i

340      has = unspecified behavior.

    =

 

341 -n

342      has = unspecified behavior.

    <= /p>

 

343 -p

344      Either (1) = clear the whole screen and then display the text (instead

345      of the = usual scrolling behavior), or (2) provide the behavior

346      specified = by ISO/IEC 9945. In the latter case, the syntax is

347      "-p = command".

    =

 

348 -t

    =

 

349      has = unspecified behavior.

    =

 

350 3.1.21 = newgrp

    =

 

351 The LSB states that implementations need = not support the -l

352 option as required in ISO/IEC = 9945.

    =

 

    =

 

353 3.1.22 od

    =

 

354 The LSB lists these as = differences.

    =

 

355 -w, = --width[=3DBYTES]

    =

 

356      outputs = BYTES bytes per output line.

    =

 

357 = --traditional

    =

 

358      accepts = arguments in pre-POSIX form described below

    =

 

359 Pre-POSIX and XSI = Specifications

    =

 

360 The LSB supports option intermixtures = with the following pre-POSIX

361 and XSI = specifications:

    =

 

362 -a

363      is = equivalent to -t a, selects named characters.

    =

 

364 -f

365      is = equivalent to -t fF, selects floats.

    =

 

366 -i

367      is = equivalent to -t d2, selects decimal two byte units

    =

 

368 -l

369      is = equivalent to -t d4, selects decimal longs.

    =

 

370 3.1.23 = renice

    =

 

371 The LSB lists the following = differences:

    =

 

372 -n = increment

    =

 

373 has unspecified = behavior.

    =

 

374 3.1.24 sed

    =

 

375 The LSB lists the following = differences:

    =

 

376 Certain aspects of internationalized = regular expressions are optional

    =

 

    =

 

377 3.1.25 = xargs

    =

 

378 The LSB lists the following = differences:

    =

 

379 -E

380      has = unspecified behavior.

    =

 

381 -I

382      has = unspecified behavior.

    =

 

383 -L

384      has = unspecified behavior.

    =

 

385 3.2  = Internationalization

    =

 

386 The LSB makes certain = internationalization aspects optional.

    =

 

387 3.2.1  Regular = Expressions

    =

 

388 Utilities that process regular = expressions shall support Basic Regular

389 Expressions and Extended Regular = Expressions as specified in ISO/IEC 9945

390 with the following = exceptions:

    =

 

391 Range expression (such as [a-z]) can be = based on code point order instead

392 of collating element = order.

    =

 

393 Equivalence class expression (such as = [=3Da=3D]) and multi-character collating

394 element expression (such as [.ch.]) are optional.

    =

 

395 Handling of a multi-character collating = element is optional.

    =

 

396 This affects at least the following = utilities: grep,  sed, and awk.

    =

 

397 3.2.2 Pattern Matching = Notation

    =

 

398 Utilities that perform Pattern Matching = Notation shall do it as specified

399 in ISO/IEC 9945 with the following = exceptions:

    =

 

400 Range expression (such as [a-z]) can be = based on code point order instead

401 of collating element = order.

    =

 

402 Equivalence class expression (such as = [=3Da=3D]) and multi-character collating

403 element expression (such as [.ch.]) are optional.

    =

 

404 Handling of a multi-character collating = element is optional.

    =

 

405 3.3 ISO/IEC 9945 Utility interfaces not = in the LSB

    =

 

406 There are a number of utility interfaces = in ISO/IEC 9945 that are not in

407 the LSB. Whilst not a direct conflict, a consequence of this is that

408 some applications written to ISO/IEC = 9945  will not port to a strict

409 LSB implementation.  It is = recommended that  development of a porting

410 guide be = considered.

  =   

 

411 A number of known areas are noted = below:

    =

 

412 Partial coverage of the User Portability Utilities option

    =

 

413 The LSB does not require a full = implementation of the

414 User Portability Utilities option, for = example it does

415 require support for the at, batch, = crontab, csplit, df, du,

416 expand, file, man, more, newgrp, nice, = patch, ps, renice, split,

417 time, and unexpand. It omits support for = alias, bg,

418 ctags, ex, fc, fg, jobs, mesg, nm, = strings, tabs, talk, tput,

419 unalias, uudecode, uuencode, vi, who and = write.

    =

 

420 Development = options

    =

 

421 The LSB does not require implementations = to support

422 the various development options with = ISO/IEC 9945.

    =

 

    =

 

423 APPENDIX A

    =

 

424 This appendix contains background = information on the POSIX

425 Standards and the Linux Standard Base specification.

    =

 

426 A1. POSIX = Standards

    =

 

427 The POSIX standards, are the foundations = of the UNIX system and Linux

428 API sets. The development body for the = POSIX standards has been

429 the IEEE in association with = ISO/JTC1/SC22/WG15.

    =

 

430 This section provides an overview of the = POSIX standards.

    =

 

431 A1.1 The Portable Application Standards Committee (PASC)

    =

 

432 The IEEE Computer Society's Portable = Application Standards Committee

433 (PASC) is the group that has and = continues to develop the POSIX family

434 of standards.  Historically, the = major work has been undertaken within

435 Project 1003 (POSIX) with the best known standard being IEEE Std 1003.1

436 (also known as POSIX 1003.1, = colloquially termed "dot 1"). The goal of

437 the PASC standards has been to promote application portability at the

438 source code = level.

    =

 

439 More Information about the Portable = Application Standards Committee

440 (PASC) is available = from:

441   = http://www.pasc.org

    =

 

442 A1.2 IEEE POSIX 1003.1 System = Application Interface (C API)

    =

 

443 Historically, this has been the base = standard upon which the POSIX

444 family of standards has been built. In = keeping with its original focus

445 on the UNIX system, it is aimed at = interactive timesharing computing

446 environments. The latest version of this standard was produced by the

447 Austin Group (see later). In general the Linux operating = system

448 aims to comply with the POSIX 1003.1 = standard.

    =

 

    =

 

449 The first edition of IEEE Std 1003.1 was published in 1988. Subsequent

450 editions were published in 1990, 1996 = and 2001. The 1990 edition was a

451 revision to the 1988 edition and became = the stable base standard onto

452 which further amendments were added. The = 1990 edition was also approved

453 as an international standard, ISO/IEC 9945-1:1990.

    =

 

454 The 1996 edition added the IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995,

455 and 1003.1i-1995 amendments to the base standard, keeping the stable core

456 text unchanged.  The 1996 edition = of IEEE Std 1003.1 was also approved

457 as an international standard, ISO/IEC 9945-1:1996.

    =

 

458 In 1998 the first real-time profile = standard, IEEE Std 1003.13-1998 was

459 published, enabling POSIX to address = embedded real-time applications

460 and smaller footprint = devices.

    =

 

461 In 1999 the decision was taken to = commence the first  major revision to

462 the core base standard in ten years, = including a merger with the 1003.2

463 standards for Shell and Utilities which = had been a separate standard

464 up to this point . It was agreed that = this work be undertaken by the

465 Austin Group (see later ). As part of this decision the PASC = decided

466 to cease rolling amendments to the base = standard after completion of

467 IEEE Stds 1003.1a, 1003.1d, 1003.1g, = 1003.1j, 1003.1q,  and 1003.2b.

468 These projects were rolled into the 2001 = edition of IEEE Std 1003.1.

469 It was decided to convert other projects = in progress to standalone

470 documents.

    =

 

    =

 

471 A1.3 IEEE POSIX 1003.2 Shell and = Utilities

    =

 

472 This standard defines a standard source = level interface to the shell

473 and utility functionality required by application programs, including

474 shell scripts. This standard has been incorporated into the IEEE Std

475 1003.1-2001 produced by the Austin = Group. The compliance level

476 of the Linux operating system is harder = to determine for the

477 shell and = utilities.

    =

 

    =

 

478 A1.4 IEEE POSIX Standards for = Real-time

    =

 

479 The PASC Real-time System Services = Working Group  (SSWG-RT) has developed

480 a series of standards that amend IEEE = Std 1003.1-1990 and a profile

481 standard (IEEE Std = 1003.13-1998).

    =

 

482 The Real-time amendments to IEEE Std = 1003.1-1990 are as follows:

483   IEEE Std 1003.1b-1993 Realtime = Extension

484   IEEE Std 1003.1c-1995 = Threads

485   IEEE Std 1003.1d-1999 Additional = Realtime Extensions

486   IEEE Std 1003.1j-2000 Advanced = Realtime Extensions

487   IEEE Std 1003.1q-2000 = Tracing

    =

 

488 These have all been folded in as options = within the revision project

489 undertaken by the Austin Group (see = below).

    <= /p>

 

490 The Real-time profile is known as IEEE = Std 1003.13-1998.  At the time

491 of writing there is a revision to IEEE = Std 1003.13-1998 in progress to

492 align it with IEEE Std 1003.1-2001, this = project current known as IEEE

493 P1003.13-200x. =

    =

 

494 A1.5 The Austin = Group

    =

 

495 The Austin Group is the working group = that manages the POSIX.1

496 specificaton. It is a joint working = group of members of the IEEE Portable

497 Applications Standards Committee, = members of The Open Group, and members

498 of ISO/IEC Joint Technical Committee 1. Participation is free and open

499 to all interested = parties.

    =

 

500 The Austin Group arose out of = discussions amongst the parties which

501 started in early 1998, which led to an = initial meeting and formation

502 of the group in September 1998. The = purpose for this group has

503 been to revise, combine, and update the following standards: ISO/IEC

504 9945-1, ISO/IEC 9945-2, IEEE Std 1003.1, = IEEE Std 1003.2, and the Base

505 Specifications of The Open Group Single = UNIX Specification.

    =

 

506 After two meetings, an agreement was = signed in July 1999 between The

507 Open Group and the Institute of = Electrical and Electronics Engineers

508 (IEEE), Inc., to formalize the project = with the first draft of the

509 revised specifications ("the revision") being made available at = the

510 same time. Under this agreement, The = Open Group and IEEE agreed to share

511 joint copyright of the resulting = work.

    =

 

512 The base document for the revision was = The Open Group's Base volumes

513 of its Single UNIX Specification, = Version 2. These were selected since

514 they were a superset of the existing = POSIX.1 and POSIX.2 specifications

515 and had some organizational aspects that = would benefit the audience for

516 the new = revision.

    =

 

517 The approach to specification = development has been one of "write once,

518 adopt everywhere", with the = deliverables being a set of specifications

519 that carry the IEEE POSIX designation, = The Open Group's Technical

520 Standard designation, and an ISO/IEC = designation (see below). This set of

521 specifications also forms the core of = the Single UNIX Specification, Version 3.

522 The Open Group and the IEEE approved the = Austin Group specifications in

523 late 2001, as The Open Group Base Specifications, Issue 6, and IEEE Std

524 1003.1-2001 respectively. ISO/IEC = approval followed about twelve

525 months = later.

    =

 

526 The Austin Group Specifications consist of the following = :

    =

 

527     * Base = Definitions, Issue 6 (XBD)

528     * Shell and = Utilities, Issue 6 (XCU)

529     * System = Interfaces, Issue 6 (XSH)

530     * Rationale = (Informative)

    =

 

531 The revision has tried to minimize the = number of changes that

532 implementations which conform to the = earlier versions of the approved

533 standards would require to bring them = into conformance with the current

534 standard. Specifically, the scope of the = project excluded doing any

535 ``new'' work, but rather collecting into = a single document what had

536 been spread across a number of = documents, and presenting it in what

537 had been proven in practice to be a more effective way. Some changes

538 to prior conforming implementations were unavoidable, primarily as a

539 consequence of resolving conflicts found = in prior revisions, or which

540 became apparent when bringing the = various pieces together.  Also, since

541 the revision now references the 1999 = version of the ISO C standard,

542 there are a number of unavoidable = changes that have been made which will

543 affect applications = portability.

    =

 

544 The 2004 edition of the 1003.1 standard = was published on April 30th

545 2004, and updates the 2001 edition of = the standard to include Technical

546 Corrigendum 1 (TC1) and Technical = Corrigendum 2 (TC2). The 2004 Edition

547 is formally known = as:

    =

 

548     IEEE Std 1003.1, = 2004 Edition

549     The Open Group = Technical Standard Base Specifications, Issue 6

550      =

551     Includes IEEE = Std 1003.1-2001, IEEE Std 1003.1-2001/Cor 1-2002 and

552     IEEE Std = 1003.1-2001/Cor 2-2004

    =

 

    =

 

553 The second technical corrigendum (TC2) = was published by

554 ISO/IEC as ISO/IEC 9945:2003/Cor-1:2004 = on September 15 2004.

    =

 

555 More information on the Austin Group, = including how to join and

556 participate is available from its web = site at

557   = http://www.opengroup.org/austin/

    =

 

558 A html version of the specification is = freely available from

559 The Open Group's Single UNIX = Specification web site at

560   = http://www.unix.org/version3/

    =

 

561 A1.5.1  Relationship to the ISO C = Standard

    =

 

562 The most recent revision to the ISO C = standard occurred in 1999.

563 The ISO C standard is itself independent = of any operating system in so

564 much as it may be implemented in many environments including

565 hosted = environments.

    =

 

566 The POSIX and Single UNIX = Specification  have a long history

567 of building on the ISO C standard and = deferring to it where applicable.

568 Revisions of POSIX.1 prior to the Austin = Group specification built upon

569 the ISO C standard by reference only, = and also allowed support for traditional

570 C as an alternative. The Single UNIX Specification in contrast,

571 included manual pages for the ISO C = interfaces.

    =

 

572 The Austin Group took the latter = approach.  The standard

573 developers believed it essential for a programmer to have a single

574 complete reference place. They also = recognized that deference to the formal

575 standard had to be addressed for the = duplicate interface definitions

576 which occur in both the ISO C standard = and their document.

    =

 

577 It was agreed that where an interface = has a version in the ISO C standard,

578 the DESCRIPTION section should describe = the relationship to the ISO C

579 standard and markings added as = appropriate within the manual page to

580 show where the ISO C standard has been = extended.

    =

 

581 A block of text was added to the start = of each affected reference

582 page stating whether the page is aligned = with the ISO C standard or

583 extended. Each page was parsed for = additions beyond the ISO C standard

584 (that is, including both POSIX and UNIX extensions), and these extensions

585 are marked as CX extensions (for C = Extensions).

    =

 

    =

 

586 A1.6 ISO/IEC = 9945

    =

 

587 In late 2002,  the ISO/IEC Joint = Technical Committee approved the joint

588 revision to POSIX and the Single UNIX Specification as an International

589 Standard. Designated as ISO/IEC = 9945:2002, the joint revision forms

590 the core of The Open Group's Single UNIX Specification Version 3 (IEEE

591 1003.1-2001, = POSIX.1).

    =

 

592 The combining of the IEEE POSIX = specifications and the Single UNIX

593 Specification into ISO/IEC 9945:2002 = Parts 1 to 4 replaces the existing

594 ISO/IEC 9945-1:1996 (IEEE 1003.1, 1996 = version), and ISO/IEC 9945-2:1993

595 (IEEE Std 1003.2, 1992 = version).

    =

 

596 ISO/IEC 9945 consists of the following = parts, under the general title

597 Information technology Portable = Operating System Interface (POSIX):

    =

 

598 Part 1: Base = Definitions

599 Part 2: System = Interfaces

600 Part 3: Shell and = Utilities

601 Part 4: = Rationale

    =

 

602 The 2003 Edition of the Austin Group specifications was published as

603 ISO/IEC 9945:2003 on August 15 = 2003.

    =

 

604 The latest technical corrigendum is due = to be published

605 shortly and is designated as ISO/IEC 9945:2003/Cor.1:2004.

    =

 

    =

 

    =

 

606 A2.2 The Linux Standard Base = Specification

    =

 

607 The Linux Standard Base (LSB) = Specification is an application binary

608 interface standard for shrink-wrapped applications.  The purpose is to

609 allow commonality amongst the many Linux distributions. 

    =

 

610 The LSB draws on the source standards of = IEEE POSIX 1003.1 and The Open

611 Group Single UNIX Specification for many = of its interfaces although does

612 not formally defer to them preferring to document any differences where

613 they exist, such as where certain = aspects of Linux cannot currently

614 conform to the industry standards, one particular example for early

615 versions of the LSB being the area of = threads.  Some interfaces are

616 not included in the LSB, since they are = outside the remit of a binary

617 runtime environment, typically these are development interfaces or user

618 level tools .  The LSB also extends = the source standards in other areas

619 (such as graphics), and includes the = necessary details such as the binary

620 execution file formats to support a high = volume application platform.

    =

 

621 Although in theory the LSB is not tied = to the GNU/Linux  operating system,

622 in practise the binary definitions are = tightly coupled to the Linux operating

623 system and the GNU C = compiler.

    =

 

624 The LSB is available as a family of specifications  supporting a

625 number of processor architectures = including IA32, PPC32, PPC64, IA64,

626 S390 and S390X.  There is a generic specification, common to all the

627 processor architectures known as the "generic LSB" (or gLSB), and  = for

628 each  processor architecture an architecture-specific specification

629 ("archLSB") describing the = details that vary by processor architecture.

    =

 

630 To support the specification,  the = LSB includes a number of

631 development tools, including test = suites, and a set of reference

632 conforming  applications.  = Binary versions of the test suites and

633 reference applications are used for = formal LSB certification of runtime

634 environments. All the major Linux = vendors today have certified LSB

635 systems.

    =

 

636 LSB 1.2, introduced in January 2002, was = the first version of the

637 specification to have an equivalent LSB certification program. LSB 1.2

638 certification, which commenced in July = 2002 is limited to the IA32 ABI.

639 LSB 1.3 certification includes = additional support for the IA64, PPC32,

640 PPC64, S390 and S390X = architectures.  At the time of writing there are

641 thirty-eight certified runtime = environments from 11 vendors.

    =

 

642 The specification is evolving quite = rapidly. LSB 1.3, introduced in

643 January 2003, adds some = internationalization, PAM, packaging, static C++

644 linking, bug fixes, plus IA64, PPC32, = S390, and S390X.

645 LSB 2.0 was completed in August 2004, = and adds some alignment

646 with ISO/IEC 9945:2003, support = for

647 C++, and the additional architectures of = AMD64 and PPC64.

648 LSB 2.0.1 was completed in October 2004, = and is a minor revision

649 in preparation for the PAS submission to = ISO.

    =

 

650 Detailed information on the LSB is = available from:

651          = http://www.linuxbase.org

652 

653 Detailed information on the LSB = Certification Program is available

654 from the LSB Certification Authority = at

655   = http://www.opengroup.org/lsb/cert/

    =

 

656 The Guide to LSB Certification is = available at:

657   = http://www.opengroup.org/lsb/cert/docs/LSB_Certification_Guide.html=

    =

 

658 The LSB Certification Register can be = viewed at:

659       =    http://www.opengroup.org/lsb/cert/register.html=

    =

 

 

Sally = Seitz

Program = Administrator

ANSI

25 = West 43rd Street

New = York, NY 10036<= /p>

Phone: (212) 642-4918

Fax: (212) 840-2298

 

------_=_NextPart_001_01C4B876.C7A3F7C0--