From sch@rosseau.sfbay.sun.com Mon Jan 22 12:07:10 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0MK79VV026567 for ; Mon, 22 Jan 2007 12:07:09 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0MK6ehn003195 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 23 Jan 2007 04:07:08 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCA00A01D7TH200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 22 Jan 2007 12:07:05 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCA005IZD7SO8B0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 22 Jan 2007 12:07:05 -0800 (PST) Received: from rosseau.sfbay.sun.com (rosseau.SFBay.Sun.COM [129.146.228.252]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0MK744A009684 for ; Mon, 22 Jan 2007 12:07:04 -0800 (PST) Received: from rosseau.sfbay.sun.com (localhost [127.0.0.1]) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0MK74cH026006 for ; Mon, 22 Jan 2007 12:07:04 -0800 (PST) Received: (from sch@localhost) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l0MK74bR026005 for PSARC-EXT@sun.com; Mon, 22 Jan 2007 12:07:04 -0800 (PST) Date: Mon, 22 Jan 2007 12:07:04 -0800 From: Stephen Hahn Subject: 2007/048 Include GNU coreutils 6.4 To: PSARC-EXT@sun.com Message-id: <20070122200704.GA25978@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 User-Agent: Mutt/1.5.7i Status: RO Content-Length: 4595 I am sponsoring the following fast track for myself. It seeks Minor release binding and is set to timeout on 31 January. The appendix contains all of the command synopses for the various coreutils commands. (Typo warning: this case has an appendix to follow; 2007/407 does not.) - Stephen ---- PSARC/2007/048 Include GNU coreutils 6.4 Stephen Hahn (sch@sun.com) ident "$Hg: d-coreutils-fast-track.txt f86d9ec9092d 2007/01/22 11:52:13 -0800 $ SMI" 1. Summary This case adds the GNU/FSF implementations of numerous standard commands, collectively known as "coreutils", under the integration guidelines for /usr/gnu [1]. 2. Discussion GNU coreutils--the combination of GNU fileutils, GNU shellutils, and GUN textutils--provide implementations of many common Unix utilities as well as various enhancements and additional related utilities. Providing these commands in a supported fashion on OpenSolaris is expected to conserve developer time, in that GNU extensions in common use on other platforms will be available on OpenSolaris, albeit on an alternate path. The coreutils package includes manual pages for the included commands; these will be installed in /usr/gnu/share/man. Conflicting commands and the complete commands are separated out in the interface table below. A new package, SUNWgnu-coreutils, will be introduced to deliver the binaries. The initial version provided will be coreutils-6.4. 2.1. Omission of GNU su(1M) Although upstream open source software can be integrated with waivers on various policies surrounding internationalization or accessibility, security policies cannot be waived. Although the current implementation of GNU su is undoubtedly well-tested, it does not interact with PAM or BSM auditing and therefore would introduce a setuid-component in violation of system policy. It is therefore omitted from the delivered components. 2.2. Apparent provision of 'g'-prefixed GNU install(1) It turns out that GNU coreutils offers its variant of install(1M) as "ginstall"--in the standard installation of the coreutils components. Since it is non-conflicting, ginstall will also be provided in /usr/bin but is not considered a precedent-setting example of a 'g'-prefixed variant. 3. Interfaces 3.1. Non-conflicting commands. /usr/bin/ [ base64 dir dircolors ginstall pinky printenv ptx readlink seq shred shuf stat tac users vdir whoami Location Uncommitted Invocation Uncommitted Human-readable output Volatile 3.2. All commands. /usr/gnu/bin/ [ base64 basename cat chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold groups head hostid hostname id install join kill link ln logname ls md5sum mkdir mkfifo mknod mv nice nl nohup od paste pathchk pinky pr printenv printf ptx pwd readlink rm rmdir seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stty sum sync tac tail tee test touch tr true tsort tty uname unexpand uniq unlink uptime users vdir wc who whoami yes Location Uncommitted Invocation Uncommitted Human-readable output Volatile /usr/share/info/coreutils.info Location Uncommitted /usr/gnu/share/man/man1/ base64.1 basename.1 cat.1 chgrp.1 chmod.1 chown.1 chroot.1 cksum.1 comm.1 cp.1 csplit.1 cut.1 date.1 dd.1 df.1 dir.1 dircolors.1 dirname.1 du.1 echo.1 env.1 expand.1 expr.1 factor.1 false.1 fmt.1 fold.1 groups.1 head.1 hostid.1 hostname.1 id.1 install.1 join.1 kill.1 link.1 ln.1 logname.1 ls.1 md5sum.1 mkdir.1 mkfifo.1 mknod.1 mv.1 nice.1 nl.1 nohup.1 od.1 paste.1 pathchk.1 pinky.1 pr.1 printenv.1 printf.1 ptx.1 pwd.1 readlink.1 rm.1 rmdir.1 seq.1 sha1sum.1 sha224sum.1 sha256sum.1 sha384sum.1 sha512sum.1 shred.1 shuf.1 sleep.1 sort.1 split.1 stat.1 stty.1 su.1 sum.1 sync.1 tac.1 tail.1 tee.1 test.1 touch.1 tr.1 true.1 tsort.1 tty.1 uname.1 unexpand.1 uniq.1 unlink.1 uptime.1 users.1 vdir.1 wc.1 who.1 whoami.1 yes.1 Location Uncommitted 4. References [1] S. Hahn, B. Smaalders, and R. Orth, PSARC/2007/047: /usr/gnu, 2007. [2] S. Hahn, PSARC/2007/049: Including GNU which, 2007. -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn@sun.com http://blogs.sun.com/sch/ From sch@rosseau.sfbay.sun.com Mon Jan 22 12:08:09 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0MK89G1026663 for ; Mon, 22 Jan 2007 12:08:09 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0MK88CL005224 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 22 Jan 2007 12:08:08 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCA00A27D9JMF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 22 Jan 2007 12:08:07 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCA005GJD9HO1D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 22 Jan 2007 12:08:05 -0800 (PST) Received: from rosseau.sfbay.sun.com (rosseau.SFBay.Sun.COM [129.146.228.252]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0MK84WK010076 for ; Mon, 22 Jan 2007 12:08:04 -0800 (PST) Received: from rosseau.sfbay.sun.com (localhost [127.0.0.1]) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0MK84RO026027 for ; Mon, 22 Jan 2007 12:08:04 -0800 (PST) Received: (from sch@localhost) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l0MK8448026026 for PSARC-EXT@sun.com; Mon, 22 Jan 2007 12:08:04 -0800 (PST) Date: Mon, 22 Jan 2007 12:08:04 -0800 From: Stephen Hahn Subject: 2007/048 Include GNU coreutils 6.4: Synopses appendix To: PSARC-EXT@sun.com Message-id: <20070122200804.GA26009@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 User-Agent: Mutt/1.5.7i Status: RO Content-Length: 128068 The following summarizes the synopses of all of the commands included in the coreutils package. - Stephen ---- PSARC/2007/048 Include GNU coreutils 6.4 Stephen Hahn (sch@sun.com) ident "$Hg: d-coreutils-appendix.txt a0bc76430dfa 2007/01/10 01:21:04 -0800 $ SMI" Appendix A. Utility synopses for GNU variant utilities A.1 [ Usage: test EXPRESSION or: test or: [ EXPRESSION ] or: [ ] or: [ OPTION Exit with the status determined by EXPRESSION. --help display this help and exit --version output version information and exit An omitted EXPRESSION defaults to false. Otherwise, EXPRESSION is true or false and sets exit status. It is one of: ( EXPRESSION ) EXPRESSION is true ! EXPRESSION EXPRESSION is false EXPRESSION1 -a EXPRESSION2 both EXPRESSION1 and EXPRESSION2 are true EXPRESSION1 -o EXPRESSION2 either EXPRESSION1 or EXPRESSION2 is true -n STRING the length of STRING is nonzero STRING equivalent to -n STRING -z STRING the length of STRING is zero STRING1 = STRING2 the strings are equal STRING1 != STRING2 the strings are not equal INTEGER1 -eq INTEGER2 INTEGER1 is equal to INTEGER2 INTEGER1 -ge INTEGER2 INTEGER1 is greater than or equal to INTEGER2 INTEGER1 -gt INTEGER2 INTEGER1 is greater than INTEGER2 INTEGER1 -le INTEGER2 INTEGER1 is less than or equal to INTEGER2 INTEGER1 -lt INTEGER2 INTEGER1 is less than INTEGER2 INTEGER1 -ne INTEGER2 INTEGER1 is not equal to INTEGER2 FILE1 -ef FILE2 FILE1 and FILE2 have the same device and inode numbers FILE1 -nt FILE2 FILE1 is newer (modification date) than FILE2 FILE1 -ot FILE2 FILE1 is older than FILE2 -b FILE FILE exists and is block special -c FILE FILE exists and is character special -d FILE FILE exists and is a directory -e FILE FILE exists -f FILE FILE exists and is a regular file -g FILE FILE exists and is set-group-ID -G FILE FILE exists and is owned by the effective group ID -h FILE FILE exists and is a symbolic link (same as -L) -k FILE FILE exists and has its sticky bit set -L FILE FILE exists and is a symbolic link (same as -h) -O FILE FILE exists and is owned by the effective user ID -p FILE FILE exists and is a named pipe -r FILE FILE exists and read permission is granted -s FILE FILE exists and has a size greater than zero -S FILE FILE exists and is a socket -t FD file descriptor FD is opened on a terminal -u FILE FILE exists and its set-user-ID bit is set -w FILE FILE exists and write permission is granted -x FILE FILE exists and execute (or search) permission is granted Except for -h and -L, all FILE-related tests dereference symbolic links. Beware that parentheses need to be escaped (e.g., by backslashes) for shells. INTEGER may also be -l STRING, which evaluates to the length of STRING. NOTE: your shell may have its own version of test and/or [, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to . A.2 base64 Usage: ./base64 [OPTION] [FILE] Base64 encode or decode FILE, or standard input, to standard output. -w, --wrap=COLS Wrap encoded lines after COLS character (default 76). Use 0 to disable line wrapping. -d, --decode Decode data. -i, --ignore-garbage When decoding, ignore non-alphabet characters. --help Display this help and exit. --version Output version information and exit. With no FILE, or when FILE is -, read standard input. The data are encoded as described for the base64 alphabet in RFC 3548. Decoding require compliant input by default, use --ignore-garbage to attempt to recover from non-alphabet characters (such as newlines) in the encoded stream. Report bugs to . A.3 basename Usage: ./basename NAME [SUFFIX] or: ./basename OPTION Print NAME with any leading directory components removed. If specified, also remove a trailing SUFFIX. --help display this help and exit --version output version information and exit Examples: ./basename /usr/bin/sort Output "sort". ./basename include/stdio.h .h Output "stdio". Report bugs to . A.4 cat Usage: ./cat [OPTION] [FILE]... Concatenate FILE(s), or standard input, to standard output. -A, --show-all equivalent to -vET -b, --number-nonblank number nonblank output lines -e equivalent to -vE -E, --show-ends display $ at end of each line -n, --number number all output lines -s, --squeeze-blank never more than one single blank line -t equivalent to -vT -T, --show-tabs display TAB characters as ^I -u (ignored) -v, --show-nonprinting use ^ and M- notation, except for LFD and TAB --help display this help and exit --version output version information and exit With no FILE, or when FILE is -, read standard input. Examples: ./cat f - g Output f's contents, then standard input, then g's contents. ./cat Copy standard input to standard output. Report bugs to . A.5 chgrp Usage: ./chgrp [OPTION]... GROUP FILE... or: ./chgrp [OPTION]... --reference=RFILE FILE... Change the group of each FILE to GROUP. With --reference, change the group of each FILE to that of RFILE. -c, --changes like verbose but report only when a change is made --dereference affect the referent of each symbolic link (this is the default), rather than the symbolic link itself -h, --no-dereference affect each symbolic link instead of any referenced file (useful only on systems that can change the ownership of a symlink) --no-preserve-root do not treat `/' specially (the default) --preserve-root fail to operate recursively on `/' -f, --silent, --quiet suppress most error messages --reference=RFILE use RFILE's group rather than specifying a GROUP value -R, --recursive operate on files and directories recursively -v, --verbose output a diagnostic for every file processed The following options modify how a hierarchy is traversed when the -R option is also specified. If more than one is specified, only the final one takes effect. -H if a command line argument is a symbolic link to a directory, traverse it -L traverse every symbolic link to a directory encountered -P do not traverse any symbolic links (default) --help display this help and exit --version output version information and exit Examples: ./chgrp staff /u Change the group of /u to "staff". ./chgrp -hR staff /u Change the group of /u and subfiles to "staff". Report bugs to . A.6 chmod Usage: ./chmod [OPTION]... MODE[,MODE]... FILE... or: ./chmod [OPTION]... OCTAL-MODE FILE... or: ./chmod [OPTION]... --reference=RFILE FILE... Change the mode of each FILE to MODE. -c, --changes like verbose but report only when a change is made --no-preserve-root do not treat `/' specially (the default) --preserve-root fail to operate recursively on `/' -f, --silent, --quiet suppress most error messages -v, --verbose output a diagnostic for every file processed --reference=RFILE use RFILE's mode instead of MODE values -R, --recursive change files and directories recursively --help display this help and exit --version output version information and exit Each MODE is of the form `[ugoa]*([-+=]([rwxXst]*|[ugo]))+'. Report bugs to . A.7 chown Usage: ./chown [OPTION]... [OWNER][:[GROUP]] FILE... or: ./chown [OPTION]... --reference=RFILE FILE... Change the owner and/or group of each FILE to OWNER and/or GROUP. With --reference, change the owner and group of each FILE to those of RFILE. -c, --changes like verbose but report only when a change is made --dereference affect the referent of each symbolic link (this is the default), rather than the symbolic link itself -h, --no-dereference affect each symbolic link instead of any referenced file (useful only on systems that can change the ownership of a symlink) --from=CURRENT_OWNER:CURRENT_GROUP change the owner and/or group of each file only if its current owner and/or group match those specified here. Either may be omitted, in which case a match is not required for the omitted attribute. --no-preserve-root do not treat `/' specially (the default) --preserve-root fail to operate recursively on `/' -f, --silent, --quiet suppress most error messages --reference=RFILE use RFILE's owner and group rather than specifying OWNER:GROUP values -R, --recursive operate on files and directories recursively -v, --verbose output a diagnostic for every file processed The following options modify how a hierarchy is traversed when the -R option is also specified. If more than one is specified, only the final one takes effect. -H if a command line argument is a symbolic link to a directory, traverse it -L traverse every symbolic link to a directory encountered -P do not traverse any symbolic links (default) --help display this help and exit --version output version information and exit Owner is unchanged if missing. Group is unchanged if missing, but changed to login group if implied by a `:' following a symbolic OWNER. OWNER and GROUP may be numeric as well as symbolic. Examples: ./chown root /u Change the owner of /u to "root". ./chown root:staff /u Likewise, but also change its group to "staff". ./chown -hR root /u Change the owner of /u and subfiles to "root". Report bugs to . A.8 chroot Usage: ./chroot NEWROOT [COMMAND...] or: ./chroot OPTION Run COMMAND with root directory set to NEWROOT. --help display this help and exit --version output version information and exit If no command is given, run ``${SHELL} -i'' (default: /bin/sh). Report bugs to . A.9 cksum Usage: ./cksum [FILE]... or: ./cksum [OPTION] Print CRC checksum and byte counts of each FILE. --help display this help and exit --version output version information and exit Report bugs to . A.0 comm Usage: ./comm [OPTION]... FILE1 FILE2 Compare sorted files FILE1 and FILE2 line by line. With no options, produce three-column output. Column one contains lines unique to FILE1, column two contains lines unique to FILE2, and column three contains lines common to both files. -1 suppress lines unique to FILE1 -2 suppress lines unique to FILE2 -3 suppress lines that appear in both files --help display this help and exit --version output version information and exit Report bugs to . A.10 cp Usage: ./cp [OPTION]... [-T] SOURCE DEST or: ./cp [OPTION]... SOURCE... DIRECTORY or: ./cp [OPTION]... -t DIRECTORY SOURCE... Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY. Mandatory arguments to long options are mandatory for short options too. -a, --archive same as -dpPR --backup[=CONTROL] make a backup of each existing destination file -b like --backup but does not accept an argument --copy-contents copy contents of special files when recursive -d same as --no-dereference --preserve=link -f, --force if an existing destination file cannot be opened, remove it and try again -i, --interactive prompt before overwrite -H follow command-line symbolic links -l, --link link files instead of copying -L, --dereference always follow symbolic links -P, --no-dereference never follow symbolic links -p same as --preserve=mode,ownership,timestamps --preserve[=ATTR_LIST] preserve the specified attributes (default: mode,ownership,timestamps), if possible additional attributes: links, all --no-preserve=ATTR_LIST don't preserve the specified attributes --parents use full source file name under DIRECTORY -R, -r, --recursive copy directories recursively --remove-destination remove each existing destination file before attempting to open it (contrast with --force) --sparse=WHEN control creation of sparse files --strip-trailing-slashes remove any trailing slashes from each SOURCE argument -s, --symbolic-link make symbolic links instead of copying -S, --suffix=SUFFIX override the usual backup suffix -t, --target-directory=DIRECTORY copy all SOURCE arguments into DIRECTORY -T, --no-target-directory treat DEST as a normal file -u, --update copy only when the SOURCE file is newer than the destination file or when the destination file is missing -v, --verbose explain what is being done -x, --one-file-system stay on this file system --help display this help and exit --version output version information and exit By default, sparse SOURCE files are detected by a crude heuristic and the corresponding DEST file is made sparse as well. That is the behavior selected by --sparse=auto. Specify --sparse=always to create a sparse DEST file whenever the SOURCE file contains a long enough sequence of zero bytes. Use --sparse=never to inhibit creation of sparse files. The backup suffix is `~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX. The version control method may be selected via the --backup option or through the VERSION_CONTROL environment variable. Here are the values: none, off never make backups (even if --backup is given) numbered, t make numbered backups existing, nil numbered if numbered backups exist, simple otherwise simple, never always make simple backups As a special case, cp makes a backup of SOURCE when the force and backup options are given and SOURCE and DEST are the same name for an existing, regular file. Report bugs to . A.11 csplit Usage: ./csplit [OPTION]... FILE PATTERN... Output pieces of FILE separated by PATTERN(s) to files `xx00', `xx01', ..., and output byte counts of each piece to standard output. Mandatory arguments to long options are mandatory for short options too. -b, --suffix-format=FORMAT use sprintf FORMAT instead of %02d -f, --prefix=PREFIX use PREFIX instead of `xx' -k, --keep-files do not remove output files on errors -n, --digits=DIGITS use specified number of digits instead of 2 -s, --quiet, --silent do not print counts of output file sizes -z, --elide-empty-files remove empty output files --help display this help and exit --version output version information and exit Read standard input if FILE is -. Each PATTERN may be: INTEGER copy up to but not including specified line number /REGEXP/[OFFSET] copy up to but not including a matching line %REGEXP%[OFFSET] skip to, but not including a matching line {INTEGER} repeat the previous pattern specified number of times {*} repeat the previous pattern as many times as possible A line OFFSET is a required `+' or `-' followed by a positive integer. Report bugs to . A.12 cut Usage: ./cut [OPTION]... [FILE]... Print selected parts of lines from each FILE to standard output. Mandatory arguments to long options are mandatory for short options too. -b, --bytes=LIST select only these bytes -c, --characters=LIST select only these characters -d, --delimiter=DELIM use DELIM instead of TAB for field delimiter -f, --fields=LIST select only these fields; also print any line that contains no delimiter character, unless the -s option is specified -n (ignored) --complement complement the set of selected bytes, characters or fields. -s, --only-delimited do not print lines not containing delimiters --output-delimiter=STRING use STRING as the output delimiter the default is to use the input delimiter --help display this help and exit --version output version information and exit Use one, and only one of -b, -c or -f. Each LIST is made up of one range, or many ranges separated by commas. Selected input is written in the same order that it is read, and is written exactly once. Each range is one of: N N'th byte, character or field, counted from 1 N- from N'th byte, character or field, to end of line N-M from N'th to M'th (included) byte, character or field -M from first to M'th (included) byte, character or field With no FILE, or when FILE is -, read standard input. Report bugs to . A.13 date Usage: ./date [OPTION]... [+FORMAT] or: ./date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]] Display the current time in the given FORMAT, or set the system date. -d, --date=STRING display time described by STRING, not `now' -f, --file=DATEFILE like --date once for each line of DATEFILE -r, --reference=FILE display the last modification time of FILE -R, --rfc-2822 output date and time in RFC 2822 format --rfc-3339=TIMESPEC output date and time in RFC 3339 format. TIMESPEC=`date', `seconds', or `ns' for date and time to the indicated precision. -s, --set=STRING set time described by STRING -u, --utc, --universal print or set Coordinated Universal Time --help display this help and exit --version output version information and exit FORMAT controls the output. The only valid option for the second form specifies Coordinated Universal Time. Interpreted sequences are: %% a literal % %a locale's abbreviated weekday name (e.g., Sun) %A locale's full weekday name (e.g., Sunday) %b locale's abbreviated month name (e.g., Jan) %B locale's full month name (e.g., January) %c locale's date and time (e.g., Thu Mar 3 23:05:25 2005) %C century; like %Y, except omit last two digits (e.g., 21) %d day of month (e.g, 01) %D date; same as %m/%d/%y %e day of month, space padded; same as %_d %F full date; same as %Y-%m-%d %g last two digits of year of ISO week number (see %G) %G year of ISO week number (see %V); normally useful only with %V %h same as %b %H hour (00..23) %I hour (01..12) %j day of year (001..366) %k hour ( 0..23) %l hour ( 1..12) %m month (01..12) %M minute (00..59) %n a newline %N nanoseconds (000000000..999999999) %p locale's equivalent of either AM or PM; blank if not known %P like %p, but lower case %r locale's 12-hour clock time (e.g., 11:11:04 PM) %R 24-hour hour and minute; same as %H:%M %s seconds since 1970-01-01 00:00:00 UTC %S second (00..60) %t a tab %T time; same as %H:%M:%S %u day of week (1..7); 1 is Monday %U week number of year, with Sunday as first day of week (00..53) %V ISO week number, with Monday as first day of week (01..53) %w day of week (0..6); 0 is Sunday %W week number of year, with Monday as first day of week (00..53) %x locale's date representation (e.g., 12/31/99) %X locale's time representation (e.g., 23:13:48) %y last two digits of year (00..99) %Y year %z +hhmm numeric timezone (e.g., -0400) %:z +hh:mm numeric timezone (e.g., -04:00) %::z +hh:mm:ss numeric time zone (e.g., -04:00:00) %:::z numeric time zone with : to necessary precision (e.g., -04, +05:30) %Z alphabetic time zone abbreviation (e.g., EDT) By default, date pads numeric fields with zeroes. The following optional flags may follow `%': - (hyphen) do not pad the field _ (underscore) pad with spaces 0 (zero) pad with zeros ^ use upper case if possible # use opposite case if possible After any flags comes an optional field width, as a decimal number; then an optional modifier, which is either E to use the locale's alternate representations if available, or O to use the locale's alternate numeric symbols if available. Report bugs to . A.14 dd Usage: ./dd [OPERAND]... or: ./dd OPTION Copy a file, converting and formatting according to the operands. bs=BYTES force ibs=BYTES and obs=BYTES cbs=BYTES convert BYTES bytes at a time conv=CONVS convert the file as per the comma separated symbol list count=BLOCKS copy only BLOCKS input blocks ibs=BYTES read BYTES bytes at a time if=FILE read from FILE instead of stdin iflag=FLAGS read as per the comma separated symbol list obs=BYTES write BYTES bytes at a time of=FILE write to FILE instead of stdout oflag=FLAGS write as per the comma separated symbol list seek=BLOCKS skip BLOCKS obs-sized blocks at start of output skip=BLOCKS skip BLOCKS ibs-sized blocks at start of input status=noxfer suppress transfer statistics BLOCKS and BYTES may be followed by the following multiplicative suffixes: xM M, c 1, w 2, b 512, kB 1000, K 1024, MB 1000*1000, M 1024*1024, GB 1000*1000*1000, G 1024*1024*1024, and so on for T, P, E, Z, Y. Each CONV symbol may be: ascii from EBCDIC to ASCII ebcdic from ASCII to EBCDIC ibm from ASCII to alternate EBCDIC block pad newline-terminated records with spaces to cbs-size unblock replace trailing spaces in cbs-size records with newline lcase change upper case to lower case nocreat do not create the output file excl fail if the output file already exists notrunc do not truncate the output file ucase change lower case to upper case swab swap every pair of input bytes noerror continue after read errors sync pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs fdatasync physically write output file data before finishing fsync likewise, but also write metadata Each FLAG symbol may be: append append mode (makes sense only for output; conv=notrunc suggested) dsync use synchronized I/O for data sync likewise, but also for metadata nonblock use non-blocking I/O noctty do not assign controlling terminal from file nofollow do not follow symlinks nolinks fail if multiply-linked Sending a USR1 signal to a running `dd' process makes it print I/O statistics to standard error and then resume copying. $ dd if=/dev/zero of=/dev/null& pid=$! $ kill -USR1 $pid; sleep 1; kill $pid 18335302+0 records in 18335302+0 records out 9387674624 bytes (9.4 GB) copied, 34.6279 seconds, 271 MB/s Options are: --help display this help and exit --version output version information and exit Report bugs to . A.15 df Usage: ./df [OPTION]... [FILE]... Show information about the file system on which each FILE resides, or all file systems by default. Mandatory arguments to long options are mandatory for short options too. -a, --all include dummy file systems -B, --block-size=SIZE use SIZE-byte blocks -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G) -H, --si likewise, but use powers of 1000 not 1024 -i, --inodes list inode information instead of block usage -k like --block-size=1K -l, --local limit listing to local file systems --no-sync do not invoke sync before getting usage info (default) -P, --portability use the POSIX output format --sync invoke sync before getting usage info -t, --type=TYPE limit listing to file systems of type TYPE -T, --print-type print file system type -x, --exclude-type=TYPE limit listing to file systems not of type TYPE -v (ignored) --help display this help and exit --version output version information and exit SIZE may be (or may be an integer optionally followed by) one of following: kB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z, Y. Report bugs to . A.16 dir Usage: ./dir [OPTION]... [FILE]... List information about the FILEs (the current directory by default). Sort entries alphabetically if none of -cftuvSUX nor --sort. Mandatory arguments to long options are mandatory for short options too. -a, --all do not ignore entries starting with . -A, --almost-all do not list implied . and .. --author with -l, print the author of each file -b, --escape print octal escapes for nongraphic characters --block-size=SIZE use SIZE-byte blocks -B, --ignore-backups do not list implied entries ending with ~ -c with -lt: sort by, and show, ctime (time of last modification of file status information) with -l: show ctime and sort by name otherwise: sort by ctime -C list entries by columns --color[=WHEN] control whether color is used to distinguish file types. WHEN may be `never', `always', or `auto' -d, --directory list directory entries instead of contents, and do not dereference symbolic links -D, --dired generate output designed for Emacs' dired mode -f do not sort, enable -aU, disable -ls --color -F, --classify append indicator (one of */=>@|) to entries --file-type likewise, except do not append `*' --format=WORD across -x, commas -m, horizontal -x, long -l, single-column -1, verbose -l, vertical -C --full-time like -l --time-style=full-iso -g like -l, but do not list owner --group-directories-first group directories before files -G, --no-group in a long listing, don't print group names -h, --human-readable with -l, print sizes in human readable format (e.g., 1K 234M 2G) --si likewise, but use powers of 1000 not 1024 -H, --dereference-command-line follow symbolic links listed on the command line --dereference-command-line-symlink-to-dir follow each command line symbolic link that points to a directory --hide=PATTERN do not list implied entries matching shell PATTERN (overridden by -a or -A) --indicator-style=WORD append indicator with style WORD to entry names: none (default), slash (-p), file-type (--file-type), classify (-F) -i, --inode print the index number of each file -I, --ignore=PATTERN do not list implied entries matching shell PATTERN -k like --block-size=1K -l use a long listing format -L, --dereference when showing file information for a symbolic link, show information for the file the link references rather than for the link itself -m fill width with a comma separated list of entries -n, --numeric-uid-gid like -l, but list numeric user and group IDs -N, --literal print raw entry names (don't treat e.g. control characters specially) -o like -l, but do not list group information -p, --indicator-style=slash append / indicator to directories -q, --hide-control-chars print ? instead of non graphic characters --show-control-chars show non graphic characters as-is (default unless program is `ls' and output is a terminal) -Q, --quote-name enclose entry names in double quotes --quoting-style=WORD use quoting style WORD for entry names: literal, locale, shell, shell-always, c, escape -r, --reverse reverse order while sorting -R, --recursive list subdirectories recursively -s, --size print the size of each file, in blocks -S sort by file size --sort=WORD sort by WORD instead of name: none -U, extension -X, size -S, time -t, version -v --time=WORD with -l, show time as WORD instead of modification time: atime -u, access -u, use -u, ctime -c, or status -c; use specified time as sort key if --sort=time --time-style=STYLE with -l, show times using style STYLE: full-iso, long-iso, iso, locale, +FORMAT. FORMAT is interpreted like `date'; if FORMAT is FORMAT1FORMAT2, FORMAT1 applies to non-recent files and FORMAT2 to recent files; if STYLE is prefixed with `posix-', STYLE takes effect only outside the POSIX locale -t sort by modification time -T, --tabsize=COLS assume tab stops at each COLS instead of 8 -u with -lt: sort by, and show, access time with -l: show access time and sort by name otherwise: sort by access time -U do not sort; list entries in directory order -v sort by version -w, --width=COLS assume screen width instead of current value -x list entries by lines instead of by columns -X sort alphabetically by entry extension -1 list one file per line --help display this help and exit --version output version information and exit SIZE may be (or may be an integer optionally followed by) one of following: kB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z, Y. By default, color is not used to distinguish types of files. That is equivalent to using --color=none. Using the --color option without the optional WHEN argument is equivalent to using --color=always. With --color=auto, color codes are output only if standard output is connected to a terminal (tty). The environment variable LS_COLORS can influence the colors, and can be set easily by the dircolors command. Exit status is 0 if OK, 1 if minor problems, 2 if serious trouble. Report bugs to . A.17 dircolors Usage: ./dircolors [OPTION]... [FILE] Output commands to set the LS_COLORS environment variable. Determine format of output: -b, --sh, --bourne-shell output Bourne shell code to set LS_COLORS -c, --csh, --c-shell output C shell code to set LS_COLORS -p, --print-database output defaults --help display this help and exit --version output version information and exit If FILE is specified, read it to determine which colors to use for which file types and extensions. Otherwise, a precompiled database is used. For details on the format of these files, run `dircolors --print-database'. Report bugs to . A.18 dirname Usage: ./dirname NAME or: ./dirname OPTION Print NAME with its trailing /component removed; if NAME contains no /'s, output `.' (meaning the current directory). --help display this help and exit --version output version information and exit Examples: ./dirname /usr/bin/sort Output "/usr/bin". ./dirname stdio.h Output ".". Report bugs to . A.19 du Usage: ./du [OPTION]... [FILE]... or: ./du [OPTION]... --files0-from=F Summarize disk usage of each FILE, recursively for directories. Mandatory arguments to long options are mandatory for short options too. -a, --all write counts for all files, not just directories --apparent-size print apparent sizes, rather than disk usage; although the apparent size is usually smaller, it may be larger due to holes in (`sparse') files, internal fragmentation, indirect blocks, and the like -B, --block-size=SIZE use SIZE-byte blocks -b, --bytes equivalent to `--apparent-size --block-size=1' -c, --total produce a grand total -D, --dereference-args dereference FILEs that are symbolic links --files0-from=F summarize disk usage of the NUL-terminated file names specified in file F -H like --si, but also evokes a warning; will soon change to be equivalent to --dereference-args (-D) -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G) --si like -h, but use powers of 1000 not 1024 -k like --block-size=1K -l, --count-links count sizes many times if hard linked -m like --block-size=1M -L, --dereference dereference all symbolic links -P, --no-dereference don't follow any symbolic links (this is the default) -0, --null end each output line with 0 byte rather than newline -S, --separate-dirs do not include size of subdirectories -s, --summarize display only a total for each argument -x, --one-file-system skip directories on different file systems -X FILE, --exclude-from=FILE Exclude files that match any pattern in FILE. --exclude=PATTERN Exclude files that match PATTERN. --max-depth=N print the total for a directory (or file, with --all) only if it is N or fewer levels below the command line argument; --max-depth=0 is the same as --summarize --time show time of the last modification of any file in the directory, or any of its subdirectories --time=WORD show time as WORD instead of modification time: atime, access, use, ctime or status --time-style=STYLE show times using style STYLE: full-iso, long-iso, iso, +FORMAT FORMAT is interpreted like `date' --help display this help and exit --version output version information and exit SIZE may be (or may be an integer optionally followed by) one of following: kB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z, Y. Report bugs to . A.20 echo Usage: ./echo [OPTION]... [STRING]... Echo the STRING(s) to standard output. -n do not output the trailing newline -e enable interpretation of backslash escapes -E disable interpretation of backslash escapes (default) --help display this help and exit --version output version information and exit If -e is in effect, the following sequences are recognized: \0NNN the character whose ASCII code is NNN (octal) \\ backslash \a alert (BEL) \b backspace \c suppress trailing newline \f form feed \n new line \r carriage return \t horizontal tab \v vertical tab NOTE: your shell may have its own version of echo, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to . A.21 env Usage: ./env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...] Set each NAME to VALUE in the environment and run COMMAND. -i, --ignore-environment start with an empty environment -u, --unset=NAME remove variable from the environment --help display this help and exit --version output version information and exit A mere - implies -i. If no COMMAND, print the resulting environment. Report bugs to . A.22 expand Usage: ./expand [OPTION]... [FILE]... Convert tabs in each FILE to spaces, writing to standard output. With no FILE, or when FILE is -, read standard input. Mandatory arguments to long options are mandatory for short options too. -i, --initial do not convert tabs after non blanks -t, --tabs=NUMBER have tabs NUMBER characters apart, not 8 -t, --tabs=LIST use comma separated list of explicit tab positions --help display this help and exit --version output version information and exit Report bugs to . A.23 expr Usage: ./expr EXPRESSION or: ./expr OPTION --help display this help and exit --version output version information and exit Print the value of EXPRESSION to standard output. A blank line below separates increasing precedence groups. EXPRESSION may be: ARG1 | ARG2 ARG1 if it is neither null nor 0, otherwise ARG2 ARG1 & ARG2 ARG1 if neither argument is null or 0, otherwise 0 ARG1 < ARG2 ARG1 is less than ARG2 ARG1 <= ARG2 ARG1 is less than or equal to ARG2 ARG1 = ARG2 ARG1 is equal to ARG2 ARG1 != ARG2 ARG1 is unequal to ARG2 ARG1 >= ARG2 ARG1 is greater than or equal to ARG2 ARG1 > ARG2 ARG1 is greater than ARG2 ARG1 + ARG2 arithmetic sum of ARG1 and ARG2 ARG1 - ARG2 arithmetic difference of ARG1 and ARG2 ARG1 * ARG2 arithmetic product of ARG1 and ARG2 ARG1 / ARG2 arithmetic quotient of ARG1 divided by ARG2 ARG1 % ARG2 arithmetic remainder of ARG1 divided by ARG2 STRING : REGEXP anchored pattern match of REGEXP in STRING match STRING REGEXP same as STRING : REGEXP substr STRING POS LENGTH substring of STRING, POS counted from 1 index STRING CHARS index in STRING where any CHARS is found, or 0 length STRING length of STRING + TOKEN interpret TOKEN as a string, even if it is a keyword like `match' or an operator like `/' ( EXPRESSION ) value of EXPRESSION Beware that many operators need to be escaped or quoted for shells. Comparisons are arithmetic if both ARGs are numbers, else lexicographical. Pattern matches return the string matched between \( and \) or null; if \( and \) are not used, they return the number of characters matched or 0. Exit status is 0 if EXPRESSION is neither null nor 0, 1 if EXPRESSION is null or 0, 2 if EXPRESSION is syntactically invalid, and 3 if an error occurred. Report bugs to . A.24 factor Usage: ./factor [NUMBER]... or: ./factor OPTION Print the prime factors of each NUMBER. --help display this help and exit --version output version information and exit Print the prime factors of all specified integer NUMBERs. If no arguments are specified on the command line, they are read from standard input. Report bugs to . A.25 false Usage: ./false [ignored command line arguments] or: ./false OPTION Exit with a status code indicating failure. --help display this help and exit --version output version information and exit NOTE: your shell may have its own version of false, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to . A.26 fmt Usage: ./fmt [-DIGITS] [OPTION]... [FILE]... Reformat each paragraph in the FILE(s), writing to standard output. If no FILE or if FILE is `-', read standard input. Mandatory arguments to long options are mandatory for short options too. -c, --crown-margin preserve indentation of first two lines -p, --prefix=STRING reformat only lines beginning with STRING, reattaching the prefix to reformatted lines -s, --split-only split long lines, but do not refill -t, --tagged-paragraph indentation of first line different from second -u, --uniform-spacing one space between words, two after sentences -w, --width=WIDTH maximum line width (default of 75 columns) --help display this help and exit --version output version information and exit With no FILE, or when FILE is -, read standard input. Report bugs to . A.27 fold Usage: ./fold [OPTION]... [FILE]... Wrap input lines in each FILE (standard input by default), writing to standard output. Mandatory arguments to long options are mandatory for short options too. -b, --bytes count bytes rather than columns -s, --spaces break at spaces -w, --width=WIDTH use WIDTH columns instead of 80 --help display this help and exit --version output version information and exit Report bugs to . A.28 ginstall Usage: ./ginstall [OPTION]... [-T] SOURCE DEST or: ./ginstall [OPTION]... SOURCE... DIRECTORY or: ./ginstall [OPTION]... -t DIRECTORY SOURCE... or: ./ginstall [OPTION]... -d DIRECTORY... In the first three forms, copy SOURCE to DEST or multiple SOURCE(s) to the existing DIRECTORY, while setting permission modes and owner/group. In the 4th form, create all components of the given DIRECTORY(ies). Mandatory arguments to long options are mandatory for short options too. --backup[=CONTROL] make a backup of each existing destination file -b like --backup but does not accept an argument -c (ignored) -d, --directory treat all arguments as directory names; create all components of the specified directories -D create all leading components of DEST except the last, then copy SOURCE to DEST -g, --group=GROUP set group ownership, instead of process' current group -m, --mode=MODE set permission mode (as in chmod), instead of rwxr-xr-x -o, --owner=OWNER set ownership (super-user only) -p, --preserve-timestamps apply access/modification times of SOURCE files to corresponding destination files -s, --strip strip symbol tables -S, --suffix=SUFFIX override the usual backup suffix -t, --target-directory=DIRECTORY copy all SOURCE arguments into DIRECTORY -T, --no-target-directory treat DEST as a normal file -v, --verbose print the name of each directory as it is created --help display this help and exit --version output version information and exit The backup suffix is `~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX. The version control method may be selected via the --backup option or through the VERSION_CONTROL environment variable. Here are the values: none, off never make backups (even if --backup is given) numbered, t make numbered backups existing, nil numbered if numbered backups exist, simple otherwise simple, never always make simple backups Report bugs to . A.29 groups Usage: ./groups [OPTION]... [USERNAME]... --help display this help and exit --version output version information and exit Same as id -Gn. If no USERNAME, use current process. Report bugs to . A.30 head Usage: ./head [OPTION]... [FILE]... Print the first 10 lines of each FILE to standard output. With more than one FILE, precede each with a header giving the file name. With no FILE, or when FILE is -, read standard input. Mandatory arguments to long options are mandatory for short options too. -c, --bytes=[-]N print the first N bytes of each file; with the leading `-', print all but the last N bytes of each file -n, --lines=[-]N print the first N lines instead of the first 10; with the leading `-', print all but the last N lines of each file -q, --quiet, --silent never print headers giving file names -v, --verbose always print headers giving file names --help display this help and exit --version output version information and exit N may have a multiplier suffix: b 512, k 1024, m 1024*1024. Report bugs to . A.31 hostid Usage: ./hostid or: ./hostid OPTION Print the numeric identifier (in hexadecimal) for the current host. --help display this help and exit --version output version information and exit Report bugs to . A.32 hostname Usage: ./hostname [NAME] or: ./hostname OPTION Print or set the hostname of the current system. --help display this help and exit --version output version information and exit Report bugs to . A.33 id Usage: ./id [OPTION]... [USERNAME] Print information for USERNAME, or the current user. -a ignore, for compatibility with other versions -g, --group print only the effective group ID -G, --groups print all group IDs -n, --name print a name instead of a number, for -ugG -r, --real print the real ID instead of the effective ID, with -ugG -u, --user print only the effective user ID --help display this help and exit --version output version information and exit Without any OPTION, print some useful set of identified information. Report bugs to . A.34 join Usage: ./join [OPTION]... FILE1 FILE2 For each pair of input lines with identical join fields, write a line to standard output. The default join field is the first, delimited by whitespace. When FILE1 or FILE2 (not both) is -, read standard input. -a FILENUM print unpairable lines coming from file FILENUM, where FILENUM is 1 or 2, corresponding to FILE1 or FILE2 -e EMPTY replace missing input fields with EMPTY -i, --ignore-case ignore differences in case when comparing fields -j FIELD equivalent to `-1 FIELD -2 FIELD' -o FORMAT obey FORMAT while constructing output line -t CHAR use CHAR as input and output field separator -v FILENUM like -a FILENUM, but suppress joined output lines -1 FIELD join on this FIELD of file 1 -2 FIELD join on this FIELD of file 2 --help display this help and exit --version output version information and exit Unless -t CHAR is given, leading blanks separate fields and are ignored, else fields are separated by CHAR. Any FIELD is a field number counted from 1. FORMAT is one or more comma or blank separated specifications, each being `FILENUM.FIELD' or `0'. Default FORMAT outputs the join field, the remaining fields from FILE1, the remaining fields from FILE2, all separated by CHAR. Important: FILE1 and FILE2 must be sorted on the join fields. E.g., use `sort -k 1b,1' if `join' has no options. Report bugs to . A.35 kill Usage: ./kill [-s SIGNAL | -SIGNAL] PID... or: ./kill -l [SIGNAL]... or: ./kill -t [SIGNAL]... Send signals to processes, or list signals. Mandatory arguments to long options are mandatory for short options too. -s, --signal=SIGNAL, -SIGNAL specify the name or number of the signal to be sent -l, --list list signal names, or convert signal names to/from numbers -t, --table print a table of signal information --help display this help and exit --version output version information and exit SIGNAL may be a signal name like `HUP', or a signal number like `1', or an exit status of a process terminated by a signal. PID is an integer; if negative it identifies a process group. NOTE: your shell may have its own version of kill, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to . A.36 link Usage: ./link FILE1 FILE2 or: ./link OPTION Call the link function to create a link named FILE2 to an existing FILE1. --help display this help and exit --version output version information and exit Report bugs to . A.37 ln Usage: ./ln [OPTION]... [-T] TARGET LINK_NAME (1st form) or: ./ln [OPTION]... TARGET (2nd form) or: ./ln [OPTION]... TARGET... DIRECTORY (3rd form) or: ./ln [OPTION]... -t DIRECTORY TARGET... (4th form) In the 1st form, create a link to TARGET with the name LINK_NAME. In the 2nd form, create a link to TARGET in the current directory. In the 3rd and 4th forms, create links to each TARGET in DIRECTORY. Create hard links by default, symbolic links with --symbolic. When creating hard links, each TARGET must exist. Mandatory arguments to long options are mandatory for short options too. --backup[=CONTROL] make a backup of each existing destination file -b like --backup but does not accept an argument -d, -F, --directory allow the superuser to attempt to hard link directories (note: will probably fail due to system restrictions, even for the superuser) -f, --force remove existing destination files -n, --no-dereference treat destination that is a symlink to a directory as if it were a normal file -i, --interactive prompt whether to remove destinations -s, --symbolic make symbolic links instead of hard links -S, --suffix=SUFFIX override the usual backup suffix -t, --target-directory=DIRECTORY specify the DIRECTORY in which to create the links -T, --no-target-directory treat LINK_NAME as a normal file -v, --verbose print name of each linked file --help display this help and exit --version output version information and exit The backup suffix is `~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX. The version control method may be selected via the --backup option or through the VERSION_CONTROL environment variable. Here are the values: none, off never make backups (even if --backup is given) numbered, t make numbered backups existing, nil numbered if numbered backups exist, simple otherwise simple, never always make simple backups Report bugs to . A.38 logname Usage: ./logname [OPTION] Print the name of the current user. --help display this help and exit --version output version information and exit Report bugs to . A.39 ls Usage: ./ls [OPTION]... [FILE]... List information about the FILEs (the current directory by default). Sort entries alphabetically if none of -cftuvSUX nor --sort. Mandatory arguments to long options are mandatory for short options too. -a, --all do not ignore entries starting with . -A, --almost-all do not list implied . and .. --author with -l, print the author of each file -b, --escape print octal escapes for nongraphic characters --block-size=SIZE use SIZE-byte blocks -B, --ignore-backups do not list implied entries ending with ~ -c with -lt: sort by, and show, ctime (time of last modification of file status information) with -l: show ctime and sort by name otherwise: sort by ctime -C list entries by columns --color[=WHEN] control whether color is used to distinguish file types. WHEN may be `never', `always', or `auto' -d, --directory list directory entries instead of contents, and do not dereference symbolic links -D, --dired generate output designed for Emacs' dired mode -f do not sort, enable -aU, disable -ls --color -F, --classify append indicator (one of */=>@|) to entries --file-type likewise, except do not append `*' --format=WORD across -x, commas -m, horizontal -x, long -l, single-column -1, verbose -l, vertical -C --full-time like -l --time-style=full-iso -g like -l, but do not list owner --group-directories-first group directories before files -G, --no-group in a long listing, don't print group names -h, --human-readable with -l, print sizes in human readable format (e.g., 1K 234M 2G) --si likewise, but use powers of 1000 not 1024 -H, --dereference-command-line follow symbolic links listed on the command line --dereference-command-line-symlink-to-dir follow each command line symbolic link that points to a directory --hide=PATTERN do not list implied entries matching shell PATTERN (overridden by -a or -A) --indicator-style=WORD append indicator with style WORD to entry names: none (default), slash (-p), file-type (--file-type), classify (-F) -i, --inode print the index number of each file -I, --ignore=PATTERN do not list implied entries matching shell PATTERN -k like --block-size=1K -l use a long listing format -L, --dereference when showing file information for a symbolic link, show information for the file the link references rather than for the link itself -m fill width with a comma separated list of entries -n, --numeric-uid-gid like -l, but list numeric user and group IDs -N, --literal print raw entry names (don't treat e.g. control characters specially) -o like -l, but do not list group information -p, --indicator-style=slash append / indicator to directories -q, --hide-control-chars print ? instead of non graphic characters --show-control-chars show non graphic characters as-is (default unless program is `ls' and output is a terminal) -Q, --quote-name enclose entry names in double quotes --quoting-style=WORD use quoting style WORD for entry names: literal, locale, shell, shell-always, c, escape -r, --reverse reverse order while sorting -R, --recursive list subdirectories recursively -s, --size print the size of each file, in blocks -S sort by file size --sort=WORD sort by WORD instead of name: none -U, extension -X, size -S, time -t, version -v --time=WORD with -l, show time as WORD instead of modification time: atime -u, access -u, use -u, ctime -c, or status -c; use specified time as sort key if --sort=time --time-style=STYLE with -l, show times using style STYLE: full-iso, long-iso, iso, locale, +FORMAT. FORMAT is interpreted like `date'; if FORMAT is FORMAT1FORMAT2, FORMAT1 applies to non-recent files and FORMAT2 to recent files; if STYLE is prefixed with `posix-', STYLE takes effect only outside the POSIX locale -t sort by modification time -T, --tabsize=COLS assume tab stops at each COLS instead of 8 -u with -lt: sort by, and show, access time with -l: show access time and sort by name otherwise: sort by access time -U do not sort; list entries in directory order -v sort by version -w, --width=COLS assume screen width instead of current value -x list entries by lines instead of by columns -X sort alphabetically by entry extension -1 list one file per line --help display this help and exit --version output version information and exit SIZE may be (or may be an integer optionally followed by) one of following: kB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z, Y. By default, color is not used to distinguish types of files. That is equivalent to using --color=none. Using the --color option without the optional WHEN argument is equivalent to using --color=always. With --color=auto, color codes are output only if standard output is connected to a terminal (tty). The environment variable LS_COLORS can influence the colors, and can be set easily by the dircolors command. Exit status is 0 if OK, 1 if minor problems, 2 if serious trouble. Report bugs to . A.40 md5sum Usage: ./md5sum [OPTION] [FILE]... Print or check MD5 (128-bit) checksums. With no FILE, or when FILE is -, read standard input. -b, --binary read in binary mode -c, --check read MD5 sums from the FILEs and check them -t, --text read in text mode (default) The following two options are useful only when verifying checksums: --status don't output anything, status code shows success -w, --warn warn about improperly formatted checksum lines --help display this help and exit --version output version information and exit The sums are computed as described in RFC 1321. When checking, the input should be a former output of this program. The default mode is to print a line with checksum, a character indicating type (`*' for binary, ` ' for text), and name for each FILE. Report bugs to . A.41 mkdir Usage: ./mkdir [OPTION] DIRECTORY... Create the DIRECTORY(ies), if they do not already exist. Mandatory arguments to long options are mandatory for short options too. -m, --mode=MODE set file mode (as in chmod), not a=rwx - umask -p, --parents no error if existing, make parent directories as needed -v, --verbose print a message for each created directory --help display this help and exit --version output version information and exit Report bugs to . A.42 mkfifo Usage: ./mkfifo [OPTION] NAME... Create named pipes (FIFOs) with the given NAMEs. Mandatory arguments to long options are mandatory for short options too. -m, --mode=MODE set file permission bits to MODE, not a=rw - umask --help display this help and exit --version output version information and exit Report bugs to . A.43 mknod Usage: ./mknod [OPTION]... NAME TYPE [MAJOR MINOR] Create the special file NAME of the given TYPE. Mandatory arguments to long options are mandatory for short options too. -m, --mode=MODE set file permission bits to MODE, not a=rw - umask --help display this help and exit --version output version information and exit Both MAJOR and MINOR must be specified when TYPE is b, c, or u, and they must be omitted when TYPE is p. If MAJOR or MINOR begins with 0x or 0X, it is interpreted as hexadecimal; otherwise, if it begins with 0, as octal; otherwise, as decimal. TYPE may be: b create a block (buffered) special file c, u create a character (unbuffered) special file p create a FIFO Report bugs to . A.44 mv Usage: ./mv [OPTION]... [-T] SOURCE DEST or: ./mv [OPTION]... SOURCE... DIRECTORY or: ./mv [OPTION]... -t DIRECTORY SOURCE... Rename SOURCE to DEST, or move SOURCE(s) to DIRECTORY. Mandatory arguments to long options are mandatory for short options too. --backup[=CONTROL] make a backup of each existing destination file -b like --backup but does not accept an argument -f, --force do not prompt before overwriting -i, --interactive prompt before overwrite --strip-trailing-slashes remove any trailing slashes from each SOURCE argument -S, --suffix=SUFFIX override the usual backup suffix -t, --target-directory=DIRECTORY move all SOURCE arguments into DIRECTORY -T, --no-target-directory treat DEST as a normal file -u, --update move only when the SOURCE file is newer than the destination file or when the destination file is missing -v, --verbose explain what is being done --help display this help and exit --version output version information and exit The backup suffix is `~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX. The version control method may be selected via the --backup option or through the VERSION_CONTROL environment variable. Here are the values: none, off never make backups (even if --backup is given) numbered, t make numbered backups existing, nil numbered if numbered backups exist, simple otherwise simple, never always make simple backups Report bugs to . A.45 nice Usage: ./nice [OPTION] [COMMAND [ARG]...] Run COMMAND with an adjusted niceness, which affects process scheduling. With no COMMAND, print the current niceness. Nicenesses range from -20 (most favorable scheduling) to 19 (least favorable). -n, --adjustment=N add integer N to the niceness (default 10) --help display this help and exit --version output version information and exit NOTE: your shell may have its own version of nice, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to . A.46 nl Usage: ./nl [OPTION]... [FILE]... Write each FILE to standard output, with line numbers added. With no FILE, or when FILE is -, read standard input. Mandatory arguments to long options are mandatory for short options too. -b, --body-numbering=STYLE use STYLE for numbering body lines -d, --section-delimiter=CC use CC for separating logical pages -f, --footer-numbering=STYLE use STYLE for numbering footer lines -h, --header-numbering=STYLE use STYLE for numbering header lines -i, --page-increment=NUMBER line number increment at each line -l, --join-blank-lines=NUMBER group of NUMBER empty lines counted as one -n, --number-format=FORMAT insert line numbers according to FORMAT -p, --no-renumber do not reset line numbers at logical pages -s, --number-separator=STRING add STRING after (possible) line number -v, --first-page=NUMBER first line number on each logical page -w, --number-width=NUMBER use NUMBER columns for line numbers --help display this help and exit --version output version information and exit By default, selects -v1 -i1 -l1 -sTAB -w6 -nrn -hn -bt -fn. CC are two delimiter characters for separating logical pages, a missing second character implies :. Type \\ for \. STYLE is one of: a number all lines t number only nonempty lines n number no lines pBRE number only lines that contain a match for the basic regular expression, BRE FORMAT is one of: ln left justified, no leading zeros rn right justified, no leading zeros rz right justified, leading zeros Report bugs to . A.47 nohup Usage: ./nohup COMMAND [ARG]... or: ./nohup OPTION Run COMMAND, ignoring hangup signals. --help display this help and exit --version output version information and exit NOTE: your shell may have its own version of nohup, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to . A.48 od Usage: ./od [OPTION]... [FILE]... or: ./od [-abcdfilosx]... [FILE] [[+]OFFSET[.][b]] or: ./od --traditional [OPTION]... [FILE] [[+]OFFSET[.][b] [+][LABEL][.][b]] Write an unambiguous representation, octal bytes by default, of FILE to standard output. With more than one FILE argument, concatenate them in the listed order to form the input. With no FILE, or when FILE is -, read standard input. All arguments to long options are mandatory for short options. -A, --address-radix=RADIX decide how file offsets are printed -j, --skip-bytes=BYTES skip BYTES input bytes first -N, --read-bytes=BYTES limit dump to BYTES input bytes -S, --strings[=BYTES] output strings of at least BYTES graphic chars -t, --format=TYPE select output format or formats -v, --output-duplicates do not use * to mark line suppression -w, --width[=BYTES] output BYTES bytes per output line --traditional accept arguments in traditional form --help display this help and exit --version output version information and exit Traditional format specifications may be intermixed; they accumulate: -a same as -t a, select named characters, ignoring high-order bit -b same as -t o1, select octal bytes -c same as -t c, select ASCII characters or backslash escapes -d same as -t u2, select unsigned decimal 2-byte units -f same as -t fF, select floats -i same as -t dI, select decimal ints -l same as -t dL, select decimal longs -o same as -t o2, select octal 2-byte units -s same as -t d2, select decimal 2-byte units -x same as -t x2, select hexadecimal 2-byte units If first and second call formats both apply, the second format is assumed if the last operand begins with + or (if there are 2 operands) a digit. An OFFSET operand means -j OFFSET. LABEL is the pseudo-address at first byte printed, incremented when dump is progressing. For OFFSET and LABEL, a 0x or 0X prefix indicates hexadecimal; suffixes may be . for octal and b for multiply by 512. TYPE is made up of one or more of these specifications: a named character, ignoring high-order bit c ASCII character or backslash escape d[SIZE] signed decimal, SIZE bytes per integer f[SIZE] floating point, SIZE bytes per integer o[SIZE] octal, SIZE bytes per integer u[SIZE] unsigned decimal, SIZE bytes per integer x[SIZE] hexadecimal, SIZE bytes per integer SIZE is a number. For TYPE in doux, SIZE may also be C for sizeof(char), S for sizeof(short), I for sizeof(int) or L for sizeof(long). If TYPE is f, SIZE may also be F for sizeof(float), D for sizeof(double) or L for sizeof(long double). RADIX is d for decimal, o for octal, x for hexadecimal or n for none. BYTES is hexadecimal with 0x or 0X prefix, it is multiplied by 512 with b suffix, by 1024 with k and by 1048576 with m. Adding a z suffix to any type adds a display of printable characters to the end of each line of output. --string without a number implies 3. --width without a number implies 32. By default, od uses -A o -t d2 -w16. Report bugs to . A.49 paste Usage: ./paste [OPTION]... [FILE]... Write lines consisting of the sequentially corresponding lines from each FILE, separated by TABs, to standard output. With no FILE, or when FILE is -, read standard input. Mandatory arguments to long options are mandatory for short options too. -d, --delimiters=LIST reuse characters from LIST instead of TABs -s, --serial paste one file at a time instead of in parallel --help display this help and exit --version output version information and exit Report bugs to . A.50 pathchk Usage: ./pathchk [OPTION]... NAME... Diagnose unportable constructs in NAME. -p check for most POSIX systems -P check for empty names and leading "-" --portability check for all POSIX systems (equivalent to -p -P) --help display this help and exit --version output version information and exit Report bugs to . A.51 pinky Usage: ./pinky [OPTION]... [USER]... -l produce long format output for the specified USERs -b omit the user's home directory and shell in long format -h omit the user's project file in long format -p omit the user's plan file in long format -s do short format output, this is the default -f omit the line of column headings in short format -w omit the user's full name in short format -i omit the user's full name and remote host in short format -q omit the user's full name, remote host and idle time in short format --help display this help and exit --version output version information and exit A lightweight `finger' program; print user information. The utmp file will be /var/adm/utmpx. Report bugs to . A.52 pr Usage: ./pr [OPTION]... [FILE]... Paginate or columnate FILE(s) for printing. Mandatory arguments to long options are mandatory for short options too. +FIRST_PAGE[:LAST_PAGE], --pages=FIRST_PAGE[:LAST_PAGE] begin [stop] printing with page FIRST_[LAST_]PAGE -COLUMN, --columns=COLUMN output COLUMN columns and print columns down, unless -a is used. Balance number of lines in the columns on each page. -a, --across print columns across rather than down, used together with -COLUMN -c, --show-control-chars use hat notation (^G) and octal backslash notation -d, --double-space double space the output -D, --date-format=FORMAT use FORMAT for the header date -e[CHAR[WIDTH]], --expand-tabs[=CHAR[WIDTH]] expand input CHARs (TABs) to tab WIDTH (8) -F, -f, --form-feed use form feeds instead of newlines to separate pages (by a 3-line page header with -F or a 5-line header and trailer without -F) -h HEADER, --header=HEADER use a centered HEADER instead of filename in page header, -h "" prints a blank line, don't use -h"" -i[CHAR[WIDTH]], --output-tabs[=CHAR[WIDTH]] replace spaces with CHARs (TABs) to tab WIDTH (8) -J, --join-lines merge full lines, turns off -W line truncation, no column alignment, --sep-string[=STRING] sets separators -l PAGE_LENGTH, --length=PAGE_LENGTH set the page length to PAGE_LENGTH (66) lines (default number of lines of text 56, and with -F 63) -m, --merge print all files in parallel, one in each column, truncate lines, but join lines of full length with -J -n[SEP[DIGITS]], --number-lines[=SEP[DIGITS]] number lines, use DIGITS (5) digits, then SEP (TAB), default counting starts with 1st line of input file -N NUMBER, --first-line-number=NUMBER start counting with NUMBER at 1st line of first page printed (see +FIRST_PAGE) -o MARGIN, --indent=MARGIN offset each line with MARGIN (zero) spaces, do not affect -w or -W, MARGIN will be added to PAGE_WIDTH -r, --no-file-warnings omit warning when a file cannot be opened -s[CHAR],--separator[=CHAR] separate columns by a single character, default for CHAR is the character without -w and 'no char' with -w -s[CHAR] turns off line truncation of all 3 column options (-COLUMN|-a -COLUMN|-m) except -w is set -SSTRING, --sep-string[=STRING] separate columns by STRING, without -S: Default separator with -J and otherwise (same as -S" "), no effect on column options -t, --omit-header omit page headers and trailers -T, --omit-pagination omit page headers and trailers, eliminate any pagination by form feeds set in input files -v, --show-nonprinting use octal backslash notation -w PAGE_WIDTH, --width=PAGE_WIDTH set page width to PAGE_WIDTH (72) characters for multiple text-column output only, -s[char] turns off (72) -W PAGE_WIDTH, --page-width=PAGE_WIDTH set page width to PAGE_WIDTH (72) characters always, truncate lines, except -J option is set, no interference with -S or -s --help display this help and exit --version output version information and exit -T implied by -l nn when nn <= 10 or <= 3 with -F. With no FILE, or when FILE is -, read standard input. Report bugs to . A.53 printenv Usage: ./printenv [VARIABLE]... or: ./printenv OPTION If no environment VARIABLE specified, print them all. --help display this help and exit --version output version information and exit NOTE: your shell may have its own version of printenv, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to . A.54 printf Usage: ./printf FORMAT [ARGUMENT]... or: ./printf OPTION Print ARGUMENT(s) according to FORMAT. --help display this help and exit --version output version information and exit FORMAT controls the output as in C printf. Interpreted sequences are: \" double quote \NNN character with octal value NNN (1 to 3 digits) \\ backslash \a alert (BEL) \b backspace \c produce no further output \f form feed \n new line \r carriage return \t horizontal tab \v vertical tab \xHH byte with hexadecimal value HH (1 to 2 digits) \uHHHH Unicode (ISO/IEC 10646) character with hex value HHHH (4 digits) \UHHHHHHHH Unicode character with hex value HHHHHHHH (8 digits) %% a single % %b ARGUMENT as a string with `\' escapes interpreted, except that octal escapes are of the form \0 or \0NNN and all C format specifications ending with one of diouxXfeEgGcs, with ARGUMENTs converted to proper type first. Variable widths are handled. NOTE: your shell may have its own version of printf, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to . A.55 ptx Usage: ./ptx [OPTION]... [INPUT]... (without -G) or: ./ptx -G [OPTION]... [INPUT [OUTPUT]] Output a permuted index, including context, of the words in the input files. Mandatory arguments to long options are mandatory for short options too. -A, --auto-reference output automatically generated references -G, --traditional behave more like System V `ptx' -F, --flag-truncation=STRING use STRING for flagging line truncations -M, --macro-name=STRING macro name to use instead of `xx' -O, --format=roff generate output as roff directives -R, --right-side-refs put references at right, not counted in -w -S, --sentence-regexp=REGEXP for end of lines or end of sentences -T, --format=tex generate output as TeX directives -W, --word-regexp=REGEXP use REGEXP to match each keyword -b, --break-file=FILE word break characters in this FILE -f, --ignore-case fold lower case to upper case for sorting -g, --gap-size=NUMBER gap size in columns between output fields -i, --ignore-file=FILE read ignore word list from FILE -o, --only-file=FILE read only word list from this FILE -r, --references first field of each line is a reference -t, --typeset-mode - not implemented - -w, --width=NUMBER output width in columns, reference excluded --help display this help and exit --version output version information and exit With no FILE or if FILE is -, read Standard Input. `-F /' by default. Report bugs to . A.56 pwd Usage: ./pwd [OPTION] Print the full filename of the current working directory. --help display this help and exit --version output version information and exit NOTE: your shell may have its own version of pwd, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to . A.57 readlink Usage: ./readlink [OPTION]... FILE Display value of a symbolic link on standard output. -f, --canonicalize canonicalize by following every symlink in every component of the given name recursively; all but the last component must exist -e, --canonicalize-existing canonicalize by following every symlink in every component of the given name recursively, all components must exist -m, --canonicalize-missing canonicalize by following every symlink in every component of the given name recursively, without requirements on components existence -n, --no-newline do not output the trailing newline -q, --quiet, -s, --silent suppress most error messages -v, --verbose report error messages --help display this help and exit --version output version information and exit Report bugs to . A.58 rm Usage: ./rm [OPTION]... FILE... Remove (unlink) the FILE(s). -f, --force ignore nonexistent files, never prompt -i prompt before every removal -I prompt once before removing more than three files, or when removing recursively. Less intrusive than -i, while still giving protection against most mistakes --interactive[=WHEN] prompt according to WHEN: never, once (-I), or always (-i). Without WHEN, prompt always --no-preserve-root do not treat `/' specially --preserve-root do not remove `/' (default) -r, -R, --recursive remove directories and their contents recursively -v, --verbose explain what is being done --help display this help and exit --version output version information and exit By default, rm does not remove directories. Use the --recursive (-r or -R) option to remove each listed directory, too, along with all of its contents. To remove a file whose name starts with a `-', for example `-foo', use one of these commands: ./rm -- -foo ./rm ./-foo Note that if you use rm to remove a file, it is usually possible to recover the contents of that file. If you want more assurance that the contents are truly unrecoverable, consider using shred. Report bugs to . A.59 rmdir Usage: ./rmdir [OPTION]... DIRECTORY... Remove the DIRECTORY(ies), if they are empty. --ignore-fail-on-non-empty ignore each failure that is solely because a directory is non-empty -p, --parents Remove DIRECTORY and its ancestors. E.g., `rmdir -p a/b/c' is similar to `rmdir a/b/c a/b a'. -v, --verbose output a diagnostic for every directory processed --help display this help and exit --version output version information and exit Report bugs to . A.60 seq Usage: ./seq [OPTION]... LAST or: ./seq [OPTION]... FIRST LAST or: ./seq [OPTION]... FIRST INCREMENT LAST Print numbers from FIRST to LAST, in steps of INCREMENT. -f, --format=FORMAT use printf style floating-point FORMAT -s, --separator=STRING use STRING to separate numbers (default: \n) -w, --equal-width equalize width by padding with leading zeroes --help display this help and exit --version output version information and exit If FIRST or INCREMENT is omitted, it defaults to 1. That is, an omitted INCREMENT defaults to 1 even when LAST is smaller than FIRST. FIRST, INCREMENT, and LAST are interpreted as floating point values. INCREMENT is usually positive if FIRST is smaller than LAST, and INCREMENT is usually negative if FIRST is greater than LAST. FORMAT must be suitable for printing one argument of type `double'; it defaults to %.PRECf if FIRST, INCREMENT, and LAST are all fixed point decimal numbers with maximum precision PREC, and to %g otherwise. Report bugs to . A.61 setuidgid Usage: ./setuidgid USERNAME COMMAND [ARGUMENT]... or: ./setuidgid OPTION Drop any supplemental groups, assume the user-ID and group-ID of the specified USERNAME, and run COMMAND with any specified ARGUMENTs. Exit with status 111 if unable to assume the required user and group ID. Otherwise, exit with the exit status of COMMAND. This program is useful only when run by root (user ID zero). --help display this help and exit --version output version information and exit Report bugs to . A.62 sha1sum Usage: ./sha1sum [OPTION] [FILE]... Print or check SHA1 (160-bit) checksums. With no FILE, or when FILE is -, read standard input. -b, --binary read in binary mode -c, --check read SHA1 sums from the FILEs and check them -t, --text read in text mode (default) The following two options are useful only when verifying checksums: --status don't output anything, status code shows success -w, --warn warn about improperly formatted checksum lines --help display this help and exit --version output version information and exit The sums are computed as described in FIPS-180-1. When checking, the input should be a former output of this program. The default mode is to print a line with checksum, a character indicating type (`*' for binary, ` ' for text), and name for each FILE. Report bugs to . A.63 sha224sum Usage: ./sha224sum [OPTION] [FILE]... Print or check SHA224 (224-bit) checksums. With no FILE, or when FILE is -, read standard input. -b, --binary read in binary mode -c, --check read SHA224 sums from the FILEs and check them -t, --text read in text mode (default) The following two options are useful only when verifying checksums: --status don't output anything, status code shows success -w, --warn warn about improperly formatted checksum lines --help display this help and exit --version output version information and exit The sums are computed as described in RFC 3874. When checking, the input should be a former output of this program. The default mode is to print a line with checksum, a character indicating type (`*' for binary, ` ' for text), and name for each FILE. Report bugs to . A.64 sha256sum Usage: ./sha256sum [OPTION] [FILE]... Print or check SHA256 (256-bit) checksums. With no FILE, or when FILE is -, read standard input. -b, --binary read in binary mode -c, --check read SHA256 sums from the FILEs and check them -t, --text read in text mode (default) The following two options are useful only when verifying checksums: --status don't output anything, status code shows success -w, --warn warn about improperly formatted checksum lines --help display this help and exit --version output version information and exit The sums are computed as described in FIPS-180-2. When checking, the input should be a former output of this program. The default mode is to print a line with checksum, a character indicating type (`*' for binary, ` ' for text), and name for each FILE. Report bugs to . A.65 sha384sum Usage: ./sha384sum [OPTION] [FILE]... Print or check SHA384 (384-bit) checksums. With no FILE, or when FILE is -, read standard input. -b, --binary read in binary mode -c, --check read SHA384 sums from the FILEs and check them -t, --text read in text mode (default) The following two options are useful only when verifying checksums: --status don't output anything, status code shows success -w, --warn warn about improperly formatted checksum lines --help display this help and exit --version output version information and exit The sums are computed as described in FIPS-180-2. When checking, the input should be a former output of this program. The default mode is to print a line with checksum, a character indicating type (`*' for binary, ` ' for text), and name for each FILE. Report bugs to . A.66 sha512sum Usage: ./sha512sum [OPTION] [FILE]... Print or check SHA512 (512-bit) checksums. With no FILE, or when FILE is -, read standard input. -b, --binary read in binary mode -c, --check read SHA512 sums from the FILEs and check them -t, --text read in text mode (default) The following two options are useful only when verifying checksums: --status don't output anything, status code shows success -w, --warn warn about improperly formatted checksum lines --help display this help and exit --version output version information and exit The sums are computed as described in FIPS-180-2. When checking, the input should be a former output of this program. The default mode is to print a line with checksum, a character indicating type (`*' for binary, ` ' for text), and name for each FILE. Report bugs to . A.67 shred Usage: ./shred [OPTIONS] FILE [...] Overwrite the specified FILE(s) repeatedly, in order to make it harder for even very expensive hardware probing to recover the data. Mandatory arguments to long options are mandatory for short options too. -f, --force change permissions to allow writing if necessary -n, --iterations=N Overwrite N times instead of the default (25) --random-source=FILE get random bytes from FILE (default /dev/urandom) -s, --size=N shred this many bytes (suffixes like K, M, G accepted) -u, --remove truncate and remove file after overwriting -v, --verbose show progress -x, --exact do not round file sizes up to the next full block; this is the default for non-regular files -z, --zero add a final overwrite with zeros to hide shredding --help display this help and exit --version output version information and exit If FILE is -, shred standard output. Delete FILE(s) if --remove (-u) is specified. The default is not to remove the files because it is common to operate on device files like /dev/hda, and those files usually should not be removed. When operating on regular files, most people use the --remove option. CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective, or is not guaranteed to be effective in all file system modes: * log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.) * file systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems * file systems that make snapshots, such as Network Appliance's NFS server * file systems that cache in temporary locations, such as NFS version 3 clients * compressed file systems In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the /etc/fstab file, as documented in the mount man page (man mount). In addition, file system backups and remote mirrors may contain copies of the file that cannot be removed, and that will allow a shredded file to be recovered later. Report bugs to . A.68 shuf Usage: ./shuf [OPTION]... [FILE] or: ./shuf -e [OPTION]... [ARG]... or: ./shuf -i LO-HI [OPTION]... Write a random permutation of the input lines to standard output. Mandatory arguments to long options are mandatory for short options too. -e, --echo treat each ARG as an input line -i, --input-range=LO-HI treat each number LO through HI as an input line -n, --head-lines=LINES output at most LINES lines -o, --output=FILE write result to FILE instead of standard output --random-source=FILE get random bytes from FILE (default /dev/urandom) -z, --zero-terminated end lines with 0 byte, not newline --help display this help and exit --version output version information and exit With no FILE, or when FILE is -, read standard input. Report bugs to . A.69 sleep Usage: ./sleep NUMBER[SUFFIX]... or: ./sleep OPTION Pause for NUMBER seconds. SUFFIX may be `s' for seconds (the default), `m' for minutes, `h' for hours or `d' for days. Unlike most implementations that require NUMBER be an integer, here NUMBER may be an arbitrary floating point number. Given two or more arguments, pause for the amount of time specified by the sum of their values. --help display this help and exit --version output version information and exit Report bugs to . A.70 sort Usage: ./sort [OPTION]... [FILE]... Write sorted concatenation of all FILE(s) to standard output. Mandatory arguments to long options are mandatory for short options too. Ordering options: -b, --ignore-leading-blanks ignore leading blanks -d, --dictionary-order consider only blanks and alphanumeric characters -f, --ignore-case fold lower case to upper case characters -g, --general-numeric-sort compare according to general numerical value -i, --ignore-nonprinting consider only printable characters -M, --month-sort compare (unknown) < `JAN' < ... < `DEC' -n, --numeric-sort compare according to string numerical value -R, --random-sort sort by random hash of keys --random-source=FILE get random bytes from FILE (default /dev/urandom) -r, --reverse reverse the result of comparisons Other options: -c, --check check whether input is sorted; do not sort -k, --key=POS1[,POS2] start a key at POS1, end it at POS2 (origin 1) -m, --merge merge already sorted files; do not sort -o, --output=FILE write result to FILE instead of standard output -s, --stable stabilize sort by disabling last-resort comparison -S, --buffer-size=SIZE use SIZE for main memory buffer -t, --field-separator=SEP use SEP instead of non-blank to blank transition -T, --temporary-directory=DIR use DIR for temporaries, not $TMPDIR or /tmp; multiple options specify multiple directories -u, --unique with -c, check for strict ordering; without -c, output only the first of an equal run -z, --zero-terminated end lines with 0 byte, not newline --help display this help and exit --version output version information and exit POS is F[.C][OPTS], where F is the field number and C the character position in the field; both are origin 1. If neither -t nor -b is in effect, characters in a field are counted from the beginning of the preceding whitespace. OPTS is one or more single-letter ordering options, which override global ordering options for that key. If no key is given, use the entire line as the key. SIZE may be followed by the following multiplicative suffixes: % 1% of memory, b 1, K 1024 (default), and so on for M, G, T, P, E, Z, Y. With no FILE, or when FILE is -, read standard input. *** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values. Report bugs to . A.71 split Usage: ./split [OPTION] [INPUT [PREFIX]] Output fixed-size pieces of INPUT to PREFIXaa, PREFIXab, ...; default size is 1000 lines, and default PREFIX is `x'. With no INPUT, or when INPUT is -, read standard input. Mandatory arguments to long options are mandatory for short options too. -a, --suffix-length=N use suffixes of length N (default 2) -b, --bytes=SIZE put SIZE bytes per output file -C, --line-bytes=SIZE put at most SIZE bytes of lines per output file -d, --numeric-suffixes use numeric suffixes instead of alphabetic -l, --lines=NUMBER put NUMBER lines per output file --verbose print a diagnostic to standard error just before each output file is opened --help display this help and exit --version output version information and exit SIZE may have a multiplier suffix: b for 512, k for 1K, m for 1 Meg. Report bugs to . A.72 stat Usage: ./stat [OPTION] FILE... Display file or file system status. -L, --dereference follow links -f, --file-system display file system status instead of file status -c --format=FORMAT use the specified FORMAT instead of the default; output a newline after each use of FORMAT --printf=FORMAT like --format, but interpret backslash escapes, and do not output a mandatory trailing newline. If you want a newline, include \n in FORMAT. -t, --terse print the information in terse form --help display this help and exit --version output version information and exit The valid format sequences for files (without --file-system): %a Access rights in octal %A Access rights in human readable form %b Number of blocks allocated (see %B) %B The size in bytes of each block reported by %b %d Device number in decimal %D Device number in hex %f Raw mode in hex %F File type %g Group ID of owner %G Group name of owner %h Number of hard links %i Inode number %n File name %N Quoted file name with dereference if symbolic link %o I/O block size %s Total size, in bytes %t Major device type in hex %T Minor device type in hex %u User ID of owner %U User name of owner %x Time of last access %X Time of last access as seconds since Epoch %y Time of last modification %Y Time of last modification as seconds since Epoch %z Time of last change %Z Time of last change as seconds since Epoch Valid format sequences for file systems: %a Free blocks available to non-superuser %b Total data blocks in file system %c Total file nodes in file system %d Free file nodes in file system %f Free blocks in file system %i File System ID in hex %l Maximum length of filenames %n File name %s Block size (for faster transfers) %S Fundamental block size (for block counts) %t Type in hex %T Type in human readable form NOTE: your shell may have its own version of stat, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to . A.73 stty Usage: ./stty [-F DEVICE] [--file=DEVICE] [SETTING]... or: ./stty [-F DEVICE] [--file=DEVICE] [-a|--all] or: ./stty [-F DEVICE] [--file=DEVICE] [-g|--save] Print or change terminal characteristics. -a, --all print all current settings in human-readable form -g, --save print all current settings in a stty-readable form -F, --file=DEVICE open and use the specified DEVICE instead of stdin --help display this help and exit --version output version information and exit Optional - before SETTING indicates negation. An * marks non-POSIX settings. The underlying system defines which settings are available. Special characters: * dsusp CHAR CHAR will send a terminal stop signal once input flushed eof CHAR CHAR will send an end of file (terminate the input) eol CHAR CHAR will end the line * eol2 CHAR alternate CHAR for ending the line erase CHAR CHAR will erase the last character typed intr CHAR CHAR will send an interrupt signal kill CHAR CHAR will erase the current line * lnext CHAR CHAR will enter the next character quoted quit CHAR CHAR will send a quit signal * rprnt CHAR CHAR will redraw the current line start CHAR CHAR will restart the output after stopping it stop CHAR CHAR will stop the output susp CHAR CHAR will send a terminal stop signal * swtch CHAR CHAR will switch to a different shell layer * werase CHAR CHAR will erase the last word typed Special settings: N set the input and output speeds to N bauds * cols N tell the kernel that the terminal has N columns * columns N same as cols N ispeed N set the input speed to N * line N use line discipline N min N with -icanon, set N characters minimum for a completed read ospeed N set the output speed to N * rows N tell the kernel that the terminal has N rows * size print the number of rows and columns according to the kernel speed print the terminal speed time N with -icanon, set read timeout of N tenths of a second Control settings: [-]clocal disable modem control signals [-]cread allow input to be received * [-]crtscts enable RTS/CTS handshaking csN set character size to N bits, N in [5..8] [-]cstopb use two stop bits per character (one with `-') [-]hup send a hangup signal when the last process closes the tty [-]hupcl same as [-]hup [-]parenb generate parity bit in output and expect parity bit in input [-]parodd set odd parity (even with `-') Input settings: [-]brkint breaks cause an interrupt signal [-]icrnl translate carriage return to newline [-]ignbrk ignore break characters [-]igncr ignore carriage return [-]ignpar ignore characters with parity errors * [-]imaxbel beep and do not flush a full input buffer on a character [-]inlcr translate newline to carriage return [-]inpck enable input parity checking [-]istrip clear high (8th) bit of input characters * [-]iutf8 assume input characters are UTF-8 encoded * [-]iuclc translate uppercase characters to lowercase * [-]ixany let any character restart output, not only start character [-]ixoff enable sending of start/stop characters [-]ixon enable XON/XOFF flow control [-]parmrk mark parity errors (with a 255-0-character sequence) [-]tandem same as [-]ixoff Output settings: * bsN backspace delay style, N in [0..1] * crN carriage return delay style, N in [0..3] * ffN form feed delay style, N in [0..1] * nlN newline delay style, N in [0..1] * [-]ocrnl translate carriage return to newline * [-]ofdel use delete characters for fill instead of null characters * [-]ofill use fill (padding) characters instead of timing for delays * [-]olcuc translate lowercase characters to uppercase * [-]onlcr translate newline to carriage return-newline * [-]onlret newline performs a carriage return * [-]onocr do not print carriage returns in the first column [-]opost postprocess output * tabN horizontal tab delay style, N in [0..3] * tabs same as tab0 * -tabs same as tab3 * vtN vertical tab delay style, N in [0..1] Local settings: [-]crterase echo erase characters as backspace-space-backspace * crtkill kill all line by obeying the echoprt and echoe settings * -crtkill kill all line by obeying the echoctl and echok settings * [-]ctlecho echo control characters in hat notation (`^c') [-]echo echo input characters * [-]echoctl same as [-]ctlecho [-]echoe same as [-]crterase [-]echok echo a newline after a kill character * [-]echoke same as [-]crtkill [-]echonl echo newline even if not echoing other characters * [-]echoprt echo erased characters backward, between `\' and '/' [-]icanon enable erase, kill, werase, and rprnt special characters [-]iexten enable non-POSIX special characters [-]isig enable interrupt, quit, and suspend special characters [-]noflsh disable flushing after interrupt and quit special characters * [-]prterase same as [-]echoprt * [-]tostop stop background jobs that try to write to the terminal * [-]xcase with icanon, escape with `\' for uppercase characters Combination settings: * [-]LCASE same as [-]lcase cbreak same as -icanon -cbreak same as icanon cooked same as brkint ignpar istrip icrnl ixon opost isig icanon, eof and eol characters to their default values -cooked same as raw crt same as echoe echoctl echoke dec same as echoe echoctl echoke -ixany intr ^c erase 0177 kill ^u * [-]decctlq same as [-]ixany ek erase and kill characters to their default values evenp same as parenb -parodd cs7 -evenp same as -parenb cs8 * [-]lcase same as xcase iuclc olcuc litout same as -parenb -istrip -opost cs8 -litout same as parenb istrip opost cs7 nl same as -icrnl -onlcr -nl same as icrnl -inlcr -igncr onlcr -ocrnl -onlret oddp same as parenb parodd cs7 -oddp same as -parenb cs8 [-]parity same as [-]evenp pass8 same as -parenb -istrip cs8 -pass8 same as parenb istrip cs7 raw same as -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -opost -isig -icanon -xcase min 1 time 0 -raw same as cooked sane same as cread -ignbrk brkint -inlcr -igncr icrnl -iutf8 -ixoff -iuclc -ixany imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke, all special characters to their default values. Handle the tty line connected to standard input. Without arguments, prints baud rate, line discipline, and deviations from stty sane. In settings, CHAR is taken literally, or coded as in ^c, 0x37, 0177 or 127; special values ^- or undef used to disable special characters. Report bugs to . A.74 sum Usage: ./sum [OPTION]... [FILE]... Print checksum and block counts for each FILE. -r defeat -s, use BSD sum algorithm, use 1K blocks -s, --sysv use System V sum algorithm, use 512 bytes blocks --help display this help and exit --version output version information and exit With no FILE, or when FILE is -, read standard input. Report bugs to . A.75 sync Usage: ./sync [OPTION] Force changed blocks to disk, update the super block. --help display this help and exit --version output version information and exit Report bugs to . A.76 tac Usage: ./tac [OPTION]... [FILE]... Write each FILE to standard output, last line first. With no FILE, or when FILE is -, read standard input. Mandatory arguments to long options are mandatory for short options too. -b, --before attach the separator before instead of after -r, --regex interpret the separator as a regular expression -s, --separator=STRING use STRING as the separator instead of newline --help display this help and exit --version output version information and exit Report bugs to . A.77 tail Usage: ./tail [OPTION]... [FILE]... Print the last 10 lines of each FILE to standard output. With more than one FILE, precede each with a header giving the file name. With no FILE, or when FILE is -, read standard input. Mandatory arguments to long options are mandatory for short options too. --retry keep trying to open a file even if it is inaccessible when tail starts or if it becomes inaccessible later; useful when following by name, i.e., with --follow=name -c, --bytes=N output the last N bytes -f, --follow[={name|descriptor}] output appended data as the file grows; -f, --follow, and --follow=descriptor are equivalent -F same as --follow=name --retry -n, --lines=N output the last N lines, instead of the last 10 --max-unchanged-stats=N with --follow=name, reopen a FILE which has not changed size after N (default 5) iterations to see if it has been unlinked or renamed (this is the usual case of rotated log files) --pid=PID with -f, terminate after process ID, PID dies -q, --quiet, --silent never output headers giving file names -s, --sleep-interval=S with -f, sleep for approximately S seconds (default 1.0) between iterations. -v, --verbose always output headers giving file names --help display this help and exit --version output version information and exit If the first character of N (the number of bytes or lines) is a `+', print beginning with the Nth item from the start of each file, otherwise, print the last N items in the file. N may have a multiplier suffix: b 512, k 1024, m 1024*1024. With --follow (-f), tail defaults to following the file descriptor, which means that even if a tail'ed file is renamed, tail will continue to track its end. This default behavior is not desirable when you really want to track the actual name of the file, not the file descriptor (e.g., log rotation). Use --follow=name in that case. That causes tail to track the named file by reopening it periodically to see if it has been removed and recreated by some other program. Report bugs to . A.78 tee Usage: ./tee [OPTION]... [FILE]... Copy standard input to each FILE, and also to standard output. -a, --append append to the given FILEs, do not overwrite -i, --ignore-interrupts ignore interrupt signals --help display this help and exit --version output version information and exit If a FILE is -, copy again to standard output. Report bugs to . A.79 touch Usage: ./touch [OPTION]... FILE... Update the access and modification times of each FILE to the current time. Mandatory arguments to long options are mandatory for short options too. -a change only the access time -c, --no-create do not create any files -d, --date=STRING parse STRING and use it instead of current time -f (ignored) -m change only the modification time -r, --reference=FILE use this file's times instead of current time -t STAMP use [[CC]YY]MMDDhhmm[.ss] instead of current time --time=WORD change the specified time: WORD is access, atime, or use: equivalent to -a WORD is modify or mtime: equivalent to -m --help display this help and exit --version output version information and exit Note that the -d and -t options accept different time-date formats. If a FILE is -, touch standard output. Report bugs to . A.80 tr Usage: ./tr [OPTION]... SET1 [SET2] Translate, squeeze, and/or delete characters from standard input, writing to standard output. -c, -C, --complement first complement SET1 -d, --delete delete characters in SET1, do not translate -s, --squeeze-repeats replace each input sequence of a repeated character that is listed in SET1 with a single occurrence of that character -t, --truncate-set1 first truncate SET1 to length of SET2 --help display this help and exit --version output version information and exit SETs are specified as strings of characters. Most represent themselves. Interpreted sequences are: \NNN character with octal value NNN (1 to 3 octal digits) \\ backslash \a audible BEL \b backspace \f form feed \n new line \r return \t horizontal tab \v vertical tab CHAR1-CHAR2 all characters from CHAR1 to CHAR2 in ascending order [CHAR*] in SET2, copies of CHAR until length of SET1 [CHAR*REPEAT] REPEAT copies of CHAR, REPEAT octal if starting with 0 [:alnum:] all letters and digits [:alpha:] all letters [:blank:] all horizontal whitespace [:cntrl:] all control characters [:digit:] all digits [:graph:] all printable characters, not including space [:lower:] all lower case letters [:print:] all printable characters, including space [:punct:] all punctuation characters [:space:] all horizontal or vertical whitespace [:upper:] all upper case letters [:xdigit:] all hexadecimal digits [=CHAR=] all characters which are equivalent to CHAR Translation occurs if -d is not given and both SET1 and SET2 appear. -t may be used only when translating. SET2 is extended to length of SET1 by repeating its last character as necessary. Excess characters of SET2 are ignored. Only [:lower:] and [:upper:] are guaranteed to expand in ascending order; used in SET2 while translating, they may only be used in pairs to specify case conversion. -s uses SET1 if not translating nor deleting; else squeezing uses SET2 and occurs after translation or deletion. Report bugs to . A.81 true Usage: ./true [ignored command line arguments] or: ./true OPTION Exit with a status code indicating success. --help display this help and exit --version output version information and exit NOTE: your shell may have its own version of true, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to . A.82 tsort Usage: ./tsort [OPTION] [FILE] Write totally ordered list consistent with the partial ordering in FILE. With no FILE, or when FILE is -, read standard input. --help display this help and exit --version output version information and exit Report bugs to . A.83 tty Usage: ./tty [OPTION]... Print the file name of the terminal connected to standard input. -s, --silent, --quiet print nothing, only return an exit status --help display this help and exit --version output version information and exit Report bugs to . A.84 uname Usage: ./uname [OPTION]... Print certain system information. With no OPTION, same as -s. -a, --all print all information, in the following order, except omit -p and -i if unknown: -s, --kernel-name print the kernel name -n, --nodename print the network node hostname -r, --kernel-release print the kernel release -v, --kernel-version print the kernel version -m, --machine print the machine hardware name -p, --processor print the processor type or "unknown" -i, --hardware-platform print the hardware platform or "unknown" -o, --operating-system print the operating system --help display this help and exit --version output version information and exit Report bugs to . A.85 unexpand Usage: ./unexpand [OPTION]... [FILE]... Convert blanks in each FILE to tabs, writing to standard output. With no FILE, or when FILE is -, read standard input. Mandatory arguments to long options are mandatory for short options too. -a, --all convert all blanks, instead of just initial blanks --first-only convert only leading sequences of blanks (overrides -a) -t, --tabs=N have tabs N characters apart instead of 8 (enables -a) -t, --tabs=LIST use comma separated LIST of tab positions (enables -a) --help display this help and exit --version output version information and exit Report bugs to . A.86 uniq Usage: ./uniq [OPTION]... [INPUT [OUTPUT]] Discard all but one of successive identical lines from INPUT (or standard input), writing to OUTPUT (or standard output). Mandatory arguments to long options are mandatory for short options too. -c, --count prefix lines by the number of occurrences -d, --repeated only print duplicate lines -D, --all-repeated[=delimit-method] print all duplicate lines delimit-method={none(default),prepend,separate} Delimiting is done with blank lines. -f, --skip-fields=N avoid comparing the first N fields -i, --ignore-case ignore differences in case when comparing -s, --skip-chars=N avoid comparing the first N characters -u, --unique only print unique lines -w, --check-chars=N compare no more than N characters in lines --help display this help and exit --version output version information and exit A field is a run of whitespace, then non-whitespace characters. Fields are skipped before chars. Report bugs to . A.87 unlink Usage: ./unlink FILE or: ./unlink OPTION Call the unlink function to remove the specified FILE. --help display this help and exit --version output version information and exit Report bugs to . A.88 uptime Usage: ./uptime [OPTION]... [ FILE ] Print the current time, the length of time the system has been up, the number of users on the system, and the average number of jobs in the run queue over the last 1, 5 and 15 minutes. If FILE is not specified, use /var/adm/utmpx. /var/adm/wtmpx as FILE is common. --help display this help and exit --version output version information and exit Report bugs to . A.89 users Usage: ./users [OPTION]... [ FILE ] Output who is currently logged in according to FILE. If FILE is not specified, use /var/adm/utmpx. /var/adm/wtmpx as FILE is common. --help display this help and exit --version output version information and exit Report bugs to . A.90 vdir Usage: ./vdir [OPTION]... [FILE]... List information about the FILEs (the current directory by default). Sort entries alphabetically if none of -cftuvSUX nor --sort. Mandatory arguments to long options are mandatory for short options too. -a, --all do not ignore entries starting with . -A, --almost-all do not list implied . and .. --author with -l, print the author of each file -b, --escape print octal escapes for nongraphic characters --block-size=SIZE use SIZE-byte blocks -B, --ignore-backups do not list implied entries ending with ~ -c with -lt: sort by, and show, ctime (time of last modification of file status information) with -l: show ctime and sort by name otherwise: sort by ctime -C list entries by columns --color[=WHEN] control whether color is used to distinguish file types. WHEN may be `never', `always', or `auto' -d, --directory list directory entries instead of contents, and do not dereference symbolic links -D, --dired generate output designed for Emacs' dired mode -f do not sort, enable -aU, disable -ls --color -F, --classify append indicator (one of */=>@|) to entries --file-type likewise, except do not append `*' --format=WORD across -x, commas -m, horizontal -x, long -l, single-column -1, verbose -l, vertical -C --full-time like -l --time-style=full-iso -g like -l, but do not list owner --group-directories-first group directories before files -G, --no-group in a long listing, don't print group names -h, --human-readable with -l, print sizes in human readable format (e.g., 1K 234M 2G) --si likewise, but use powers of 1000 not 1024 -H, --dereference-command-line follow symbolic links listed on the command line --dereference-command-line-symlink-to-dir follow each command line symbolic link that points to a directory --hide=PATTERN do not list implied entries matching shell PATTERN (overridden by -a or -A) --indicator-style=WORD append indicator with style WORD to entry names: none (default), slash (-p), file-type (--file-type), classify (-F) -i, --inode print the index number of each file -I, --ignore=PATTERN do not list implied entries matching shell PATTERN -k like --block-size=1K -l use a long listing format -L, --dereference when showing file information for a symbolic link, show information for the file the link references rather than for the link itself -m fill width with a comma separated list of entries -n, --numeric-uid-gid like -l, but list numeric user and group IDs -N, --literal print raw entry names (don't treat e.g. control characters specially) -o like -l, but do not list group information -p, --indicator-style=slash append / indicator to directories -q, --hide-control-chars print ? instead of non graphic characters --show-control-chars show non graphic characters as-is (default unless program is `ls' and output is a terminal) -Q, --quote-name enclose entry names in double quotes --quoting-style=WORD use quoting style WORD for entry names: literal, locale, shell, shell-always, c, escape -r, --reverse reverse order while sorting -R, --recursive list subdirectories recursively -s, --size print the size of each file, in blocks -S sort by file size --sort=WORD sort by WORD instead of name: none -U, extension -X, size -S, time -t, version -v --time=WORD with -l, show time as WORD instead of modification time: atime -u, access -u, use -u, ctime -c, or status -c; use specified time as sort key if --sort=time --time-style=STYLE with -l, show times using style STYLE: full-iso, long-iso, iso, locale, +FORMAT. FORMAT is interpreted like `date'; if FORMAT is FORMAT1FORMAT2, FORMAT1 applies to non-recent files and FORMAT2 to recent files; if STYLE is prefixed with `posix-', STYLE takes effect only outside the POSIX locale -t sort by modification time -T, --tabsize=COLS assume tab stops at each COLS instead of 8 -u with -lt: sort by, and show, access time with -l: show access time and sort by name otherwise: sort by access time -U do not sort; list entries in directory order -v sort by version -w, --width=COLS assume screen width instead of current value -x list entries by lines instead of by columns -X sort alphabetically by entry extension -1 list one file per line --help display this help and exit --version output version information and exit SIZE may be (or may be an integer optionally followed by) one of following: kB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z, Y. By default, color is not used to distinguish types of files. That is equivalent to using --color=none. Using the --color option without the optional WHEN argument is equivalent to using --color=always. With --color=auto, color codes are output only if standard output is connected to a terminal (tty). The environment variable LS_COLORS can influence the colors, and can be set easily by the dircolors command. Exit status is 0 if OK, 1 if minor problems, 2 if serious trouble. Report bugs to . A.91 wc Usage: ./wc [OPTION]... [FILE]... or: ./wc [OPTION]... --files0-from=F Print newline, word, and byte counts for each FILE, and a total line if more than one FILE is specified. With no FILE, or when FILE is -, read standard input. -c, --bytes print the byte counts -m, --chars print the character counts -l, --lines print the newline counts --files0-from=F read input from the files specified by NUL-terminated names in file F -L, --max-line-length print the length of the longest line -w, --words print the word counts --help display this help and exit --version output version information and exit Report bugs to . A.92 who Usage: ./who [OPTION]... [ FILE | ARG1 ARG2 ] -a, --all same as -b -d --login -p -r -t -T -u -b, --boot time of last system boot -d, --dead print dead processes -H, --heading print line of column headings -l, --login print system login processes --lookup attempt to canonicalize hostnames via DNS -m only hostname and user associated with stdin -p, --process print active processes spawned by init -q, --count all login names and number of users logged on -r, --runlevel print current runlevel -s, --short print only name, line, and time (default) -t, --time print last system clock change -T, -w, --mesg add user's message status as +, - or ? -u, --users list users logged in --message same as -T --writable same as -T --help display this help and exit --version output version information and exit If FILE is not specified, use /var/adm/utmpx. /var/adm/wtmpx as FILE is common. If ARG1 ARG2 given, -m presumed: `am i' or `mom likes' are usual. Report bugs to . A.93 whoami Usage: ./whoami [OPTION]... Print the user name associated with the current effective user ID. Same as id -un. --help display this help and exit --version output version information and exit Report bugs to . A.94 yes Usage: ./yes [STRING]... or: ./yes OPTION Repeatedly output a line with all specified STRING(s), or `y'. --help display this help and exit --version output version information and exit Report bugs to . -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn@sun.com http://blogs.sun.com/sch/ From sommerfeld@sun.com Mon Jan 22 14:30:08 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0MMU8PP000951 for ; Mon, 22 Jan 2007 14:30:08 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0MMU67t002643; Mon, 22 Jan 2007 14:30:07 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCA00B0XJU3IP00@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Jan 2007 14:30:03 -0800 (PST) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCA001F3JU2WZ80@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Jan 2007 14:30:02 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0MMU0W1022964; Mon, 22 Jan 2007 17:30:00 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0MMU0Ln028816; Mon, 22 Jan 2007 17:30:00 -0500 (EST) Date: Mon, 22 Jan 2007 17:29:59 -0500 From: Bill Sommerfeld Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070122200704.GA25978@eng.sun.com> To: Stephen Hahn Cc: PSARC-EXT@sun.com Message-id: <1169504999.28083.37.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> Status: RO Content-Length: 1125 I've found a few detail-related issues with this proposal. Overall, I'm concerned that this case is too large to review as a single fasttrack, and might have been better presented as several individual fasttracks over the course of several weeks. specific issues: wes-1 "printenv", "whoami", and "users" are currently delivered in solaris in /usr/ucb. Are the versions you propose to deliver as part of this project upwards-compatible with the /usr/ucb variants? wes-2 With respect to "shred": the limitations of this tool in the Solaris environment need to be very carefully documented. I'd like to see it withdrawn from this case to get appropriate individual scrutiny. wes-3 "sha1sum", "sha224sum", "sha256sum", "sha384sum" and "sha512sum" are listed as conflicting commands but as far as I can tell aren't delivered into /usr/bin on solaris. wes-4 the sha*sum commands (and any other commands delivered by this project which use cryptographic hashes) should use one of the existing hash function implementations in Solaris rather than delivering a new copy. (see libmd(3LIB)). - Bill From sch@rosseau.sfbay.sun.com Mon Jan 22 14:50:19 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0MMoHDf001531 for ; Mon, 22 Jan 2007 14:50:18 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0MMnWXo017851; Tue, 23 Jan 2007 06:50:16 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCA00C29KROOF00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Jan 2007 14:50:12 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCA00ME4KROIN70@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Jan 2007 14:50:12 -0800 (PST) Received: from rosseau.sfbay.sun.com (rosseau.SFBay.Sun.COM [129.146.228.252]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0MMoCbO004640; Mon, 22 Jan 2007 14:50:12 -0800 (PST) Received: from rosseau.sfbay.sun.com (localhost [127.0.0.1]) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0MMoB2M026189; Mon, 22 Jan 2007 14:50:11 -0800 (PST) Received: (from sch@localhost) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l0MMoAeO026188; Mon, 22 Jan 2007 14:50:10 -0800 (PST) Date: Mon, 22 Jan 2007 14:49:51 -0800 From: Stephen Hahn Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <1169504999.28083.37.camel@thunk> To: Bill Sommerfeld Cc: PSARC-EXT@sun.com Message-id: <20070122224951.GF24874@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2304 * Bill Sommerfeld [2007-01-22 14:30]: > I've found a few detail-related issues with this proposal. Overall, I'm > concerned that this case is too large to review as a single fasttrack, > and might have been better presented as several individual fasttracks > over the course of several weeks. Noted. I am happy to extend the timer on this case, with the short term focus going to 047 and 049. > specific issues: > > wes-1 "printenv", "whoami", and "users" are currently delivered in > solaris in /usr/ucb. Are the versions you propose to deliver > as part of this project upwards-compatible with the /usr/ucb > variants? Unknown at this time. I am not sure that I agree that tools delivered in /usr/bin need to be upwards compatible with a specific environment's implementation, if that environment never delivered its implementations into the default path. > wes-2 With respect to "shred": the limitations of this tool in the > Solaris environment need to be very carefully documented. > I'd like to see it withdrawn from this case to get appropriate > individual scrutiny. Unless further discussion arises, I will amend to withdraw. I assume that this request is similar in spirit to the current non-delivery of GNU su. > wes-3 "sha1sum", "sha224sum", "sha256sum", "sha384sum" and "sha512sum" > are listed as conflicting commands but as far as I can tell > aren't delivered into /usr/bin on solaris. Darren Moffat asked to reserve /usr/bin/sha*sum for future work in the Security Community. As a result, these conflict with "existing or anticipated components" (2007/047, 2.4), and remain only in /usr/gnu. > wes-4 the sha*sum commands (and any other commands delivered by this > project which use cryptographic hashes) should use one of the > existing hash function implementations in Solaris rather than > delivering a new copy. (see libmd(3LIB)). Disagree on economic grounds. The cryptographic functions in the package are Project Private and, at present, deviation would introduce a maintenance cost not borne by other distributions that choose to include these utilities. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn@sun.com http://blogs.sun.com/sch/ From nw141292@binky.Central.Sun.COM Mon Jan 22 15:02:46 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0MN2kVU002077 for ; Mon, 22 Jan 2007 15:02:46 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0MN2j425742; Mon, 22 Jan 2007 16:02:45 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCA00I03LCLIN00@brm-avmta-1.central.sun.com>; Mon, 22 Jan 2007 16:02:45 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCA00G8FLCKTZ10@brm-avmta-1.central.sun.com>; Mon, 22 Jan 2007 16:02:45 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0MN2Knh003777; Mon, 22 Jan 2007 17:02:20 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0MN2KV2003776; Mon, 22 Jan 2007 17:02:20 -0600 (CST) Date: Mon, 22 Jan 2007 17:02:20 -0600 From: Nicolas Williams Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070122224951.GF24874@eng.sun.com> To: Stephen Hahn Cc: Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <20070122230219.GT12298@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 710 On Mon, Jan 22, 2007 at 02:49:51PM -0800, Stephen Hahn wrote: > * Bill Sommerfeld [2007-01-22 14:30]: > > wes-4 the sha*sum commands (and any other commands delivered by this > > project which use cryptographic hashes) should use one of the > > existing hash function implementations in Solaris rather than > > delivering a new copy. (see libmd(3LIB)). > > Disagree on economic grounds. The cryptographic functions in the > package are Project Private and, at present, deviation would introduce > a maintenance cost not borne by other distributions that choose to > include these utilities. Couldn't these be implemented as simple shell script wrappers around digest(1)? From sommerfeld@Sun.COM Mon Jan 22 15:52:19 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0MNqJfY002651 for ; Mon, 22 Jan 2007 15:52:19 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0MNqJ5j020156; Mon, 22 Jan 2007 15:52:19 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCA0000VNN7PI00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Jan 2007 15:52:19 -0800 (PST) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCA00MW2NN5IMC0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Jan 2007 15:52:18 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0MNqGcx010206; Mon, 22 Jan 2007 18:52:16 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0MNqGtD029156; Mon, 22 Jan 2007 18:52:16 -0500 (EST) Date: Mon, 22 Jan 2007 18:52:15 -0500 From: Bill Sommerfeld Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070122224951.GF24874@eng.sun.com> To: Stephen Hahn Cc: PSARC-EXT@Sun.COM Message-id: <1169509935.28083.65.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> Status: RO Content-Length: 2358 On Mon, 2007-01-22 at 14:49 -0800, Stephen Hahn wrote: > > wes-1 "printenv", "whoami", and "users" are currently delivered in > > solaris in /usr/ucb. Are the versions you propose to deliver > > as part of this project upwards-compatible with the /usr/ucb > > variants? > > Unknown at this time. I am not sure that I agree that tools delivered > in /usr/bin need to be upwards compatible with a specific > environment's implementation, if that environment never delivered its > implementations into the default path. Please investigate this. > > > wes-2 With respect to "shred": the limitations of this tool in the > > Solaris environment need to be very carefully documented. > > I'd like to see it withdrawn from this case to get appropriate > > individual scrutiny. > > Unless further discussion arises, I will amend to withdraw. I assume > that this request is similar in spirit to the current non-delivery of > GNU su. No. I believe this issue can be resolved through documentation updates. > > wes-4 the sha*sum commands (and any other commands delivered by this > > project which use cryptographic hashes) should use one of the > > existing hash function implementations in Solaris rather than > > delivering a new copy. (see libmd(3LIB)). > > Disagree on economic grounds. The cryptographic functions in the > package are Project Private and, at present, deviation would introduce > a maintenance cost not borne by other distributions that choose to > include these utilities. I don't believe this analysis is as straightforward as you think. We do processor-specific performance tuning of many cryptographic algorithms; by delivering additional implementations, you either (a) dilute the value of this performance tuning effort, or (b) require the additional implementations to be tuned, which will more than eliminate any savings from delivering a redundant implementation. This may also complicate cryptographic certification. I've taken a look at the code; the engineering effort required appears small if we extend libmd to add the *_stream() calls used by the coreutils md5sum (which is the basis of all the sha*sum utilities). One additional issue: wes-5 It appears that current version of coreutils is 6.7, not 6.4. Why aren't we integrating the newest available version? From scott.rotondo@sun.com Mon Jan 22 16:03:23 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0N03MS2003105 for ; Mon, 22 Jan 2007 16:03:22 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0N03KDI008975; Tue, 23 Jan 2007 00:03:21 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCA00I09O5K2D00@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Jan 2007 16:03:20 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCA0010NO5KWYD0@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Jan 2007 16:03:20 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0N03JGi016007; Mon, 22 Jan 2007 16:03:19 -0800 (PST) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l0N03JP01649; Mon, 22 Jan 2007 16:03:19 -0800 (PST) Date: Mon, 22 Jan 2007 16:03:19 -0800 From: Scott Rotondo Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <1169509935.28083.65.camel@thunk> To: Bill Sommerfeld Cc: Stephen Hahn , PSARC-EXT@sun.com Message-id: <45B550C7.1060707@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> User-Agent: Mail/News 1.5.0.4 (X11/20060718) Status: RO Content-Length: 1265 Bill Sommerfeld wrote: >>> wes-4 the sha*sum commands (and any other commands delivered by this >>> project which use cryptographic hashes) should use one of the >>> existing hash function implementations in Solaris rather than >>> delivering a new copy. (see libmd(3LIB)). >> Disagree on economic grounds. The cryptographic functions in the >> package are Project Private and, at present, deviation would introduce >> a maintenance cost not borne by other distributions that choose to >> include these utilities. > > I don't believe this analysis is as straightforward as you think. > > We do processor-specific performance tuning of many cryptographic > algorithms; by delivering additional implementations, you either (a) > dilute the value of this performance tuning effort, or (b) require the > additional implementations to be tuned, which will more than eliminate > any savings from delivering a redundant implementation. > > This may also complicate cryptographic certification. We also strongly discourage duplication of cryptographic implementations because it complicates export approval. That's not a huge concern for digest functions, but in general it's another reason to prefer centralized crypto implementations. Scott From sch@rosseau.sfbay.sun.com Mon Jan 22 16:29:03 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0N0T2wm003530 for ; Mon, 22 Jan 2007 16:29:02 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0N0T2401196; Mon, 22 Jan 2007 17:29:02 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCA00705PCC4M00@brm-avmta-1.central.sun.com>; Mon, 22 Jan 2007 17:29:00 -0700 (MST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCA00GQWPCCTZ50@brm-avmta-1.central.sun.com>; Mon, 22 Jan 2007 17:29:00 -0700 (MST) Received: from rosseau.sfbay.sun.com (rosseau.SFBay.Sun.COM [129.146.228.252]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0N0T0K9026023; Mon, 22 Jan 2007 16:29:00 -0800 (PST) Received: from rosseau.sfbay.sun.com (localhost [127.0.0.1]) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0N0Sx7a026455; Mon, 22 Jan 2007 16:28:59 -0800 (PST) Received: (from sch@localhost) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l0N0Sx4O026454; Mon, 22 Jan 2007 16:28:59 -0800 (PST) Date: Mon, 22 Jan 2007 16:28:59 -0800 From: Stephen Hahn Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <1169509935.28083.65.camel@thunk> To: Bill Sommerfeld Cc: PSARC-EXT@sun.com Message-id: <20070123002859.GI24874@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 3625 * Bill Sommerfeld [2007-01-22 15:52]: > On Mon, 2007-01-22 at 14:49 -0800, Stephen Hahn wrote: > > > wes-1 "printenv", "whoami", and "users" are currently delivered in > > > solaris in /usr/ucb. Are the versions you propose to deliver > > > as part of this project upwards-compatible with the /usr/ucb > > > variants? > > > > Unknown at this time. I am not sure that I agree that tools delivered > > in /usr/bin need to be upwards compatible with a specific > > environment's implementation, if that environment never delivered its > > implementations into the default path. > > Please investigate this. The printenv and whoami implementations are compatible, although the GNU variants offer --help and --version. The users implementations differ, in that the GNU variant's output matches "who -q", but the UCB variant selects a smaller set of valid utmpx entries to display. (I expect this is a bug in our UCB implementation, as users(1B) claims it should match the output of "who -q".) > > > wes-2 With respect to "shred": the limitations of this tool in the > > > Solaris environment need to be very carefully documented. > > > I'd like to see it withdrawn from this case to get appropriate > > > individual scrutiny. > > > > Unless further discussion arises, I will amend to withdraw. I assume > > that this request is similar in spirit to the current non-delivery of > > GNU su. > > No. I believe this issue can be resolved through documentation updates. Understood. Will postpone to a separate case. > > > wes-4 the sha*sum commands (and any other commands delivered by this > > > project which use cryptographic hashes) should use one of the > > > existing hash function implementations in Solaris rather than > > > delivering a new copy. (see libmd(3LIB)). > > > > Disagree on economic grounds. The cryptographic functions in the > > package are Project Private and, at present, deviation would introduce > > a maintenance cost not borne by other distributions that choose to > > include these utilities. > > I don't believe this analysis is as straightforward as you think. > > We do processor-specific performance tuning of many cryptographic > algorithms; by delivering additional implementations, you either (a) > dilute the value of this performance tuning effort, or (b) require the > additional implementations to be tuned, which will more than eliminate > any savings from delivering a redundant implementation. I disagree with the premise that an alternative implementation must have (or make a best effort to achieve) equivalent performance to the default implementation. > This may also complicate cryptographic certification. > > I've taken a look at the code; the engineering effort required appears > small if we extend libmd to add the *_stream() calls used by the > coreutils md5sum (which is the basis of all the sha*sum utilities). Will follow up with Security Community regards certification. At present, the intent is to leave upstream source unchanged. If that means these commands are dropped, that's an outcome consistent with the conflict in constraining policies. > One additional issue: > > wes-5 It appears that current version of coreutils is 6.7, not 6.4. > Why aren't we integrating the newest available version? I hadn't realized that a new release had been made since my pull in November. Case will be updated for 6.7. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn@sun.com http://blogs.sun.com/sch/ From David.Comay@sun.com Mon Jan 22 16:41:15 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0N0fEwh003654 for ; Mon, 22 Jan 2007 16:41:15 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0N0f9Xl016309; Tue, 23 Jan 2007 08:41:10 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCA00L01PWM5O00@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Jan 2007 16:41:10 -0800 (PST) Received: from police.SFBay.Sun.COM ([129.146.228.53]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCA001ISPWLWYE0@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Jan 2007 16:41:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by police.SFBay.Sun.COM (8.13.7+Sun/8.13.7) with ESMTP id l0N0f73j026343; Mon, 22 Jan 2007 16:41:07 -0800 (PST) Date: Mon, 22 Jan 2007 16:41:07 -0800 (PST) From: David.Comay@sun.com Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070122224951.GF24874@eng.sun.com> Sender: comay@police.SFBay.Sun.COM To: Darren.Moffat@sun.com, Stephen Hahn Cc: Bill Sommerfeld , PSARC-EXT@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> Status: RO Content-Length: 744 [ adding Darren directly to the thread ] >> wes-3 "sha1sum", "sha224sum", "sha256sum", "sha384sum" and "sha512sum" >> are listed as conflicting commands but as far as I can tell >> aren't delivered into /usr/bin on solaris. > > Darren Moffat asked to reserve /usr/bin/sha*sum for future work in the > Security Community. As a result, these conflict with "existing or > anticipated components" (2007/047, 2.4), and remain only in /usr/gnu. I'm a little bit uncomfortable about reserving this command namespace in the absence of a concrete proposal from the Security Community. Or has there been such a proposal yet? If not, is it expected to be a straightforward wrapper around digest(1) or is there something else intended here? dsc From sommerfeld@sun.com Mon Jan 22 16:55:47 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0N0tl2s004073 for ; Mon, 22 Jan 2007 16:55:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0N0tkTa005267; Mon, 22 Jan 2007 16:55:46 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCA00M0BQKYAZ00@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Jan 2007 16:55:46 -0800 (PST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCA001VJQKXXDE0@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Jan 2007 16:55:45 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0N0tiTk029527; Mon, 22 Jan 2007 19:55:44 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0N0tiVH029533; Mon, 22 Jan 2007 19:55:44 -0500 (EST) Date: Mon, 22 Jan 2007 19:55:43 -0500 From: Bill Sommerfeld Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070123002859.GI24874@eng.sun.com> To: Stephen Hahn Cc: PSARC-EXT@sun.com Message-id: <1169513743.28083.74.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <20070123002859.GI24874@eng.sun.com> Status: RO Content-Length: 354 On Mon, 2007-01-22 at 16:28 -0800, Stephen Hahn wrote: > If that > means [the sha*sum] commands are dropped, that's an outcome consistent with > the conflict in constraining policies. I don't see this as an acceptable resolution; programs or scripts written to depend on coreutils may not run unless we supply these utilities. - Bill From jek3@sun.com Mon Jan 22 17:29:42 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0N1TgJk004489 for ; Mon, 22 Jan 2007 17:29:42 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0N1Tgum003930; Mon, 22 Jan 2007 17:29:42 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCA00E05S5HBH00@brm-avmta-1.central.sun.com>; Mon, 22 Jan 2007 18:29:41 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.228.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCA00GHLS5HU780@brm-avmta-1.central.sun.com>; Mon, 22 Jan 2007 18:29:41 -0700 (MST) Received: from [129.150.12.43] (vpn-129-150-12-43.SFBay.Sun.COM [129.150.12.43]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0N1Teh0198513; Mon, 22 Jan 2007 17:29:40 -0800 (PST) Date: Mon, 22 Jan 2007 15:28:05 -1000 From: Joseph Kowalski Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070122224951.GF24874@eng.sun.com> To: Stephen Hahn Cc: Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <45B564A5.40005@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1190 Stephen Hahn wrote: >> >> wes-1 "printenv", "whoami", and "users" are currently delivered in >> solaris in /usr/ucb. Are the versions you propose to deliver >> as part of this project upwards-compatible with the /usr/ucb >> variants? >> > > Unknown at this time. I am not sure that I agree that tools delivered > in /usr/bin need to be upwards compatible with a specific > environment's implementation, if that environment never delivered its > implementations into the default path. > First, let me say that in the general case, I agree with Stephen. However, I'm not sure that /usr/ucb/bin isn't a special case. Many moons ago, to transition from Solaris 1 to Solaris 2, we encouraged: PATH=/usr/ucb/bin:/usr/ccs/bin:/usr/bin and then later encouraged: PATH=/usr/ccs/bin:/usr/bin:/usr/ucb/bin My point is this might be rather common. Then again, it may be so many moons ago that it doesn't matter. Hence, in the interest of due diligence, I'd request the team to evaluate the degree of compatibility. (I suspect they are probably pretty close.) Finding them incompatable does not automatically create a problem. We should just know. - jek3 From jek3@sun.com Mon Jan 22 17:37:05 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0N1b4Ro004637 for ; Mon, 22 Jan 2007 17:37:05 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0N1b3Yr004923; Mon, 22 Jan 2007 17:37:04 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCA0020NSHRI200@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Jan 2007 17:37:03 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.108.38]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCA00NUKSHQ2490@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Jan 2007 17:37:02 -0800 (PST) Received: from [129.150.12.43] (vpn-129-150-12-43.SFBay.Sun.COM [129.150.12.43]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0N1b14A200066; Mon, 22 Jan 2007 17:37:01 -0800 (PST) Date: Mon, 22 Jan 2007 15:35:26 -1000 From: Joseph Kowalski Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B564A5.40005@sun.com> To: Joseph Kowalski Cc: Stephen Hahn , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <45B5665E.7020907@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <45B564A5.40005@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1489 Joseph Kowalski wrote: > Stephen Hahn wrote: >>> >>> wes-1 "printenv", "whoami", and "users" are currently delivered in >>> solaris in /usr/ucb. Are the versions you propose to deliver >>> as part of this project upwards-compatible with the /usr/ucb >>> variants? >>> >> >> Unknown at this time. I am not sure that I agree that tools delivered >> in /usr/bin need to be upwards compatible with a specific >> environment's implementation, if that environment never delivered its >> implementations into the default path. >> > First, let me say that in the general case, I agree with Stephen. > > However, I'm not sure that /usr/ucb/bin isn't a special case. Many > moons ago, to > transition from Solaris 1 to Solaris 2, we encouraged: > > PATH=/usr/ucb/bin:/usr/ccs/bin:/usr/bin > > and then later encouraged: > > PATH=/usr/ccs/bin:/usr/bin:/usr/ucb/bin > > My point is this might be rather common. Then again, it may be so > many moons > ago that it doesn't matter. > > Hence, in the interest of due diligence, I'd request the team to > evaluate the degree > of compatibility. (I suspect they are probably pretty close.) Finding > them incompatable > does not automatically create a problem. We should just know. > > - jek3 Seeing additional mail along this thread, these utilities are indeed compatable - or compatible enough for me. (Its 90%+ that gnu and our manpage are right about users and our implementation is wrong.) - jek3 From Darren.Moffat@sun.com Tue Jan 23 03:07:41 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NB7e8X014118 for ; Tue, 23 Jan 2007 03:07:40 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0NB7Br7011191; Tue, 23 Jan 2007 19:07:36 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCB00117IWKA200@brm-avmta-1.central.sun.com>; Tue, 23 Jan 2007 04:07:32 -0700 (MST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCB00HT7IWIQJE0@brm-avmta-1.central.sun.com>; Tue, 23 Jan 2007 04:07:31 -0700 (MST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NB7THU001329; Tue, 23 Jan 2007 11:07:29 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCB00J01IUTG100@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 23 Jan 2007 11:07:29 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCB006YZIWB4T00@d1-emea-09.sun.com>; Tue, 23 Jan 2007 11:07:24 +0000 (GMT) Date: Tue, 23 Jan 2007 11:07:23 +0000 From: Darren J Moffat Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: Sender: Darren.Moffat@sun.com To: David.Comay@sun.com Cc: Stephen Hahn , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <45B5EC6B.9040203@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 908 David.Comay@sun.com wrote: > [ adding Darren directly to the thread ] > >>> wes-3 "sha1sum", "sha224sum", "sha256sum", "sha384sum" and >>> "sha512sum" >>> are listed as conflicting commands but as far as I can tell >>> aren't delivered into /usr/bin on solaris. >> >> Darren Moffat asked to reserve /usr/bin/sha*sum for future work in the >> Security Community. As a result, these conflict with "existing or >> anticipated components" (2007/047, 2.4), and remain only in /usr/gnu. > > I'm a little bit uncomfortable about reserving this command namespace > in the absence of a concrete proposal from the Security Community. Or > has there been such a proposal yet? If not, is it expected to be a > straightforward wrapper around digest(1) or is there something else > intended here? PSARC/2005/530 digest(1) md5/md5sum compatibility Basically sets this up already. -- Darren J Moffat From Darren.Moffat@sun.com Tue Jan 23 03:12:36 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NBCZAG014160 for ; Tue, 23 Jan 2007 03:12:36 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0NBCVtW026457; Tue, 23 Jan 2007 11:12:35 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCB00409J4XR800@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jan 2007 03:12:33 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCB00JD9J4WPF50@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jan 2007 03:12:33 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NBCW0h025642; Tue, 23 Jan 2007 11:12:32 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCB00D01HVL3C00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 23 Jan 2007 11:12:32 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCB00605J4Q4T10@d1-emea-09.sun.com>; Tue, 23 Jan 2007 11:12:27 +0000 (GMT) Date: Tue, 23 Jan 2007 11:12:26 +0000 From: Darren J Moffat Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <1169509935.28083.65.camel@thunk> Sender: Darren.Moffat@sun.com To: Bill Sommerfeld Cc: Stephen Hahn , PSARC-EXT@sun.com Message-id: <45B5ED9A.3090902@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 3458 Bill Sommerfeld wrote: > On Mon, 2007-01-22 at 14:49 -0800, Stephen Hahn wrote: >>> wes-1 "printenv", "whoami", and "users" are currently delivered in >>> solaris in /usr/ucb. Are the versions you propose to deliver >>> as part of this project upwards-compatible with the /usr/ucb >>> variants? >> >> Unknown at this time. I am not sure that I agree that tools delivered >> in /usr/bin need to be upwards compatible with a specific >> environment's implementation, if that environment never delivered its >> implementations into the default path. > > Please investigate this. > >>> wes-2 With respect to "shred": the limitations of this tool in the >>> Solaris environment need to be very carefully documented. >>> I'd like to see it withdrawn from this case to get appropriate >>> individual scrutiny. >> Unless further discussion arises, I will amend to withdraw. I assume >> that this request is similar in spirit to the current non-delivery of >> GNU su. > > No. I believe this issue can be resolved through documentation updates. > >>> wes-4 the sha*sum commands (and any other commands delivered by this >>> project which use cryptographic hashes) should use one of the >>> existing hash function implementations in Solaris rather than >>> delivering a new copy. (see libmd(3LIB)). >> Disagree on economic grounds. The cryptographic functions in the >> package are Project Private and, at present, deviation would introduce >> a maintenance cost not borne by other distributions that choose to >> include these utilities. > > I don't believe this analysis is as straightforward as you think. > > We do processor-specific performance tuning of many cryptographic > algorithms; by delivering additional implementations, you either (a) > dilute the value of this performance tuning effort, or (b) require the > additional implementations to be tuned, which will more than eliminate > any savings from delivering a redundant implementation. > > This may also complicate cryptographic certification. Here I believe Bill means FIPS 140-2 certification not "US Export approval". We are currently going through a FIPS 140-2 export approval for Solaris (and I do mean Solaris not OpenSolaris - contact me offline if you want to know why there is a difference here). If this case introduces a additional implementation of algorithms covered by FIPS (which the SHA2 suite is but MD5 is not) then we need to make it clear to out customers that if they use digest(1) they are using the FIPS approved versions but if they use the /usr/gnu/bin/sha*sum variants they are not. I'd rather not have to make that distinction. The SHA2 suite of algorithms has a common API and libmd (PSARC 2005/426) was introduced with a Committed (nee Stable) taxonomy explicitly so that commands like this could use it rather than having to provide their own. > I've taken a look at the code; the engineering effort required appears > small if we extend libmd to add the *_stream() calls used by the > coreutils md5sum (which is the basis of all the sha*sum utilities). Given that libmd is designed to be compatible with libmd on other systems for exactly this reason if we need to add *_stream() interfaces then I'm more than happy to do so. Given there are multiple issues with these specific commands I would highly recommend that they been dealt with in a case other than this one. -- Darren J Moffat From Darren.Moffat@sun.com Tue Jan 23 03:14:19 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NBEIT5014182 for ; Tue, 23 Jan 2007 03:14:18 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0NBEEWD026849; Tue, 23 Jan 2007 11:14:17 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCB00J2DJ7Q8V00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 03:14:14 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCB00D5YJ7PO030@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 03:14:14 -0800 (PST) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NBEC2V026002; Tue, 23 Jan 2007 11:14:13 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCB00701J2F9S00@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 23 Jan 2007 11:14:12 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCB005EHJ7O8F00@d1-emea-10.sun.com>; Tue, 23 Jan 2007 11:14:12 +0000 (GMT) Date: Tue, 23 Jan 2007 11:14:12 +0000 From: Darren J Moffat Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070122230219.GT12298@binky.Central.Sun.COM> Sender: Darren.Moffat@sun.com To: Nicolas Williams Cc: Stephen Hahn , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <45B5EE04.1050906@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <20070122230219.GT12298@binky.Central.Sun.COM> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 906 Nicolas Williams wrote: > On Mon, Jan 22, 2007 at 02:49:51PM -0800, Stephen Hahn wrote: >> * Bill Sommerfeld [2007-01-22 14:30]: >>> wes-4 the sha*sum commands (and any other commands delivered by this >>> project which use cryptographic hashes) should use one of the >>> existing hash function implementations in Solaris rather than >>> delivering a new copy. (see libmd(3LIB)). >> Disagree on economic grounds. The cryptographic functions in the >> package are Project Private and, at present, deviation would introduce >> a maintenance cost not borne by other distributions that choose to >> include these utilities. > > Couldn't these be implemented as simple shell script wrappers around > digest(1)? simple shell script wrapper probably not but maybe. PSARC/2005/530 has been approved but not yet delivered (due to resource constraints). -- Darren J Moffat From carlsonj@phorcys.east.sun.com Tue Jan 23 05:30:29 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NDUSn0017833 for ; Tue, 23 Jan 2007 05:30:29 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0NDUQn04247; Tue, 23 Jan 2007 06:30:26 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCB00G09PIP3600@brm-avmta-1.central.sun.com>; Tue, 23 Jan 2007 06:30:25 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCB005V4PIOCZ60@brm-avmta-1.central.sun.com>; Tue, 23 Jan 2007 06:30:25 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0NDUOxx011912; Tue, 23 Jan 2007 08:30:24 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0NDUOdp011909; Tue, 23 Jan 2007 08:30:24 -0500 (EST) Date: Tue, 23 Jan 2007 08:30:24 -0500 From: James Carlson Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B5EC6B.9040203@Sun.COM> To: Darren J Moffat Cc: David.Comay@sun.com, PSARC-EXT@sun.com Message-id: <17846.3568.413518.243946@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <45B5EC6B.9040203@Sun.COM> Status: RO Content-Length: 980 Darren J Moffat writes: > David.Comay@sun.com wrote: > > [ adding Darren directly to the thread ] > > > >>> wes-3 "sha1sum", "sha224sum", "sha256sum", "sha384sum" and > >>> "sha512sum" > >>> are listed as conflicting commands but as far as I can tell > >>> aren't delivered into /usr/bin on solaris. [...] > PSARC/2005/530 digest(1) md5/md5sum compatibility > > Basically sets this up already. Something seems out of joint. Though I can find no reservations by those names in any ARC document, it seems that the reservations would have were made here are for these very same utilities. Now that these utilities finally arrive, we're compelled to put them off into a /usr/gnu ghetto because they now conflict with themselves. How is that? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sch@rosseau.sfbay.sun.com Tue Jan 23 11:11:57 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NJBuB9000663 for ; Tue, 23 Jan 2007 11:11:56 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0NJBoYE003412; Tue, 23 Jan 2007 19:11:55 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC0090L5BRYG00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 11:11:51 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC002E85BQWD70@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 11:11:50 -0800 (PST) Received: from rosseau.sfbay.sun.com (rosseau.SFBay.Sun.COM [129.146.228.252]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0NJBnYd000075; Tue, 23 Jan 2007 11:11:49 -0800 (PST) Received: from rosseau.sfbay.sun.com (localhost [127.0.0.1]) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0NJBn3w027178; Tue, 23 Jan 2007 11:11:49 -0800 (PST) Received: (from sch@localhost) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l0NJBn3m027177; Tue, 23 Jan 2007 11:11:49 -0800 (PST) Date: Tue, 23 Jan 2007 11:11:44 -0800 From: Stephen Hahn Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B5ED9A.3090902@Sun.COM> To: Darren J Moffat Cc: Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <20070123191144.GD27099@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1710 * Darren J Moffat [2007-01-23 03:12]: > >I've taken a look at the code; the engineering effort required appears > >small if we extend libmd to add the *_stream() calls used by the > >coreutils md5sum (which is the basis of all the sha*sum utilities). > > Given that libmd is designed to be compatible with libmd on other > systems for exactly this reason if we need to add *_stream() interfaces > then I'm more than happy to do so. > > Given there are multiple issues with these specific commands I would > highly recommend that they been dealt with in a case other than this one. That bring us to two choices for sha*sum: A. These commands will be withdrawn from this case. As far as I can see, the appropriate steps are: 1. File RFE against libmd5 for the new *_stream() interfaces. 2. Make upstream code corrections to sha*sum. 3. Await release of coreutils version with changes accepted. 4. File supplementary case, advertising inclusion of additional commands. B. The commands will be provided, with requirements that 1. "Non-FIPS" disclaimer text will be added to required manual pages. 2. Code/functionality duplication accepted, as these implementations are common across a variety of platforms and downstream deviation presents an ongoing maintenance cost. (shred is already en route to handling similar to B. su is being omitted based on an assessment that the cost of steps similar to A would be uneconomic.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn@sun.com http://blogs.sun.com/sch/ From casper@holland.sun.com Tue Jan 23 11:20:30 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NJKUgC001466 for ; Tue, 23 Jan 2007 11:20:30 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0NJKTn01188; Tue, 23 Jan 2007 12:20:29 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC00D215Q4PU00@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jan 2007 11:20:28 -0800 (PST) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC006WK5Q1XR40@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jan 2007 11:20:26 -0800 (PST) Received: from vaticaan.holland.sun.com (vaticaan.Holland.Sun.COM [129.159.214.1]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NJKNjo017698; Tue, 23 Jan 2007 19:20:23 +0000 (GMT) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NJKMqq002418; Tue, 23 Jan 2007 20:20:23 +0100 (MET) Date: Tue, 23 Jan 2007 20:20:22 +0100 From: Casper.Dik@sun.com Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070123191144.GD27099@eng.sun.com> Sender: casper@holland.sun.com To: Stephen Hahn Cc: Darren J Moffat , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> Status: RO Content-Length: 625 > B. The commands will be provided, with requirements that > > 1. "Non-FIPS" disclaimer text will be added to required > manual pages. > > 2. Code/functionality duplication accepted, as these > implementations are common across a variety of platforms > and downstream deviation presents an ongoing maintenance > cost. > > (shred is already en route to handling similar to B. su is being > omitted based on an assessment that the cost of steps similar to A > would be uneconomic.) > Isn't it the case that schred does not work on ZFS so why provide it at all? Casper From sch@rosseau.sfbay.sun.com Tue Jan 23 11:43:03 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NJh2U4002674 for ; Tue, 23 Jan 2007 11:43:02 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0NJguZs021374; Wed, 24 Jan 2007 03:43:00 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC007056RMGL00@brm-avmta-1.central.sun.com>; Tue, 23 Jan 2007 12:42:58 -0700 (MST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC006T06RLZCC0@brm-avmta-1.central.sun.com>; Tue, 23 Jan 2007 12:42:58 -0700 (MST) Received: from rosseau.sfbay.sun.com (rosseau.SFBay.Sun.COM [129.146.228.252]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0NJgtmg016094; Tue, 23 Jan 2007 11:42:55 -0800 (PST) Received: from rosseau.sfbay.sun.com (localhost [127.0.0.1]) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0NJgtjv027209; Tue, 23 Jan 2007 11:42:55 -0800 (PST) Received: (from sch@localhost) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l0NJgt2Y027208; Tue, 23 Jan 2007 11:42:55 -0800 (PST) Date: Tue, 23 Jan 2007 11:42:55 -0800 From: Stephen Hahn Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> To: Casper.Dik@sun.com Cc: Darren J Moffat , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <20070123194255.GA27140@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1267 * Casper.Dik@Sun.COM [2007-01-23 11:20]: > > > B. The commands will be provided, with requirements that > > > > 1. "Non-FIPS" disclaimer text will be added to required > > manual pages. > > > > 2. Code/functionality duplication accepted, as these > > implementations are common across a variety of platforms > > and downstream deviation presents an ongoing maintenance > > cost. > > > > (shred is already en route to handling similar to B. su is being > > omitted based on an assessment that the cost of steps similar to A > > would be uneconomic.) > > Isn't it the case that schred does not work on ZFS so why provide > it at all? Yes, shred won't work on ZFS. Bill and Dan were just telling me that snapshots mean it can never really work, so it's probably best to drop it. There are various actions the ZFS team might take to decrease unintended data recovery, but shred isn't equivalent to any of them. I suppose the question is whether the command should be modified to warn about "failure to shred on this filesystem", or simply dropped. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn@sun.com http://blogs.sun.com/sch/ From nw141292@binky.Central.Sun.COM Tue Jan 23 11:46:05 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NJk4fe002968 for ; Tue, 23 Jan 2007 11:46:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0NJjqp1022465; Wed, 24 Jan 2007 03:46:00 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC00F0F6WMER00@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jan 2007 11:45:58 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC006A96WLY960@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jan 2007 11:45:57 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0NJjUs4010901; Tue, 23 Jan 2007 13:45:30 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0NJjTiY010900; Tue, 23 Jan 2007 13:45:29 -0600 (CST) Date: Tue, 23 Jan 2007 13:45:29 -0600 From: Nicolas Williams Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> To: Casper.Dik@sun.com Cc: Stephen Hahn , Darren J Moffat , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <20070123194529.GJ9523@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 717 On Tue, Jan 23, 2007 at 08:20:22PM +0100, Casper.Dik@Sun.COM wrote: > > (shred is already en route to handling similar to B. su is being > > omitted based on an assessment that the cost of steps similar to A > > would be uneconomic.) > > Isn't it the case that schred does not work on ZFS so why provide > it at all? That's what I would think. It would be dangerous to provide a utility like shred if it doesn't know to error out for files in ZFS. So it should least be modified to be ZFS aware. Since ZFS might not be the only COW filesystem (think BSD 4.4 LFS) it may be a good idea to come up with a generic interface for querying whether writes to a file overwrite the same disk blocks or not. Nico -- From nw141292@binky.Central.Sun.COM Tue Jan 23 11:49:26 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NJnQ1f003046 for ; Tue, 23 Jan 2007 11:49:26 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0NJnGf5014614; Tue, 23 Jan 2007 19:49:25 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC0082L72B6L00@brm-avmta-1.central.sun.com>; Tue, 23 Jan 2007 12:49:23 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC006S3728ZPB0@brm-avmta-1.central.sun.com>; Tue, 23 Jan 2007 12:49:21 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0NJmu4h010928; Tue, 23 Jan 2007 13:48:56 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0NJmuaZ010927; Tue, 23 Jan 2007 13:48:56 -0600 (CST) Date: Tue, 23 Jan 2007 13:48:56 -0600 From: Nicolas Williams Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070123194255.GA27140@eng.sun.com> To: Stephen Hahn Cc: Casper.Dik@sun.com, Darren J Moffat , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <20070123194855.GK9523@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194255.GA27140@eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1070 On Tue, Jan 23, 2007 at 11:42:55AM -0800, Stephen Hahn wrote: > Yes, shred won't work on ZFS. Bill and Dan were just telling me that > snapshots mean it can never really work, so it's probably best to drop > it. There are various actions the ZFS team might take to decrease > unintended data recovery, but shred isn't equivalent to any of them. Snapshots aren't the primary issue. The real issue is COW. Snapshots simply mean that to shred a file you have to find all cloned copies and shred them and then destroy any read-only snapshots that still reference the un-shredded file, then shred the original, and do it atomically w.r.t. further snapshot activity. Painful, but possibly doable, whereas COW means you simply can't shred in user-land without support from the filesystem. > I suppose the question is whether the command should be modified to > warn about "failure to shred on this filesystem", or simply dropped. We should want to have a NIST-compliant shred facility. Wouldn't then the sha*sum FIPS compliance issue come in here as well? From sch@rosseau.sfbay.sun.com Tue Jan 23 11:53:41 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NJreIh003158 for ; Tue, 23 Jan 2007 11:53:40 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0NJren05904; Tue, 23 Jan 2007 12:53:40 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC00F1Z79EUX00@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jan 2007 11:53:38 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC006S779EY960@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jan 2007 11:53:38 -0800 (PST) Received: from rosseau.sfbay.sun.com (rosseau.SFBay.Sun.COM [129.146.228.252]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0NJrZNo021636; Tue, 23 Jan 2007 11:53:35 -0800 (PST) Received: from rosseau.sfbay.sun.com (localhost [127.0.0.1]) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0NJrZAf027253; Tue, 23 Jan 2007 11:53:35 -0800 (PST) Received: (from sch@localhost) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l0NJrZJL027252; Tue, 23 Jan 2007 11:53:35 -0800 (PST) Date: Tue, 23 Jan 2007 11:53:35 -0800 From: Stephen Hahn Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070123194529.GJ9523@binky.Central.Sun.COM> To: Nicolas Williams Cc: Casper.Dik@sun.com, Darren J Moffat , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <20070123195335.GF27099@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1574 * Nicolas Williams [2007-01-23 11:45]: > On Tue, Jan 23, 2007 at 08:20:22PM +0100, Casper.Dik@Sun.COM wrote: > > > (shred is already en route to handling similar to B. su is being > > > omitted based on an assessment that the cost of steps similar to A > > > would be uneconomic.) > > > > Isn't it the case that schred does not work on ZFS so why provide > > it at all? > > That's what I would think. It would be dangerous to provide a utility > like shred if it doesn't know to error out for files in ZFS. > > So it should least be modified to be ZFS aware. Since ZFS might not be > the only COW filesystem (think BSD 4.4 LFS) it may be a good idea to > come up with a generic interface for querying whether writes to a file > overwrite the same disk blocks or not. Well, this seems like an entree to make my economic point. We cannot staff each OSS integration effort such that it could modify a significant subset of commands (or the system) to meet policies and/or advised changes on initial integration; the freeware team is at best able to choose to ship or omit components. (This choice means that, in some cases, dependencies will not be satisfied that might have been satisfied on other systems.) If an incoming set of bug reports/customer calls implies that additional investment is justified, then that team will have to come back to declare their new proposed interfaces. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn@sun.com http://blogs.sun.com/sch/ From nw141292@binky.Central.Sun.COM Tue Jan 23 12:06:26 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NK6Qd2003612 for ; Tue, 23 Jan 2007 12:06:26 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0NK6LGX017224; Tue, 23 Jan 2007 12:06:24 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC00G4L7UO9L00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 12:06:24 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC0028U7ULWKD0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 12:06:22 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0NK5vIl011036; Tue, 23 Jan 2007 14:05:57 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0NK5v5t011035; Tue, 23 Jan 2007 14:05:57 -0600 (CST) Date: Tue, 23 Jan 2007 14:05:57 -0600 From: Nicolas Williams Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070123195335.GF27099@eng.sun.com> To: Stephen Hahn Cc: Casper.Dik@sun.com, Darren J Moffat , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <20070123200556.GM9523@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1706 On Tue, Jan 23, 2007 at 11:53:35AM -0800, Stephen Hahn wrote: > * Nicolas Williams [2007-01-23 11:45]: > > That's what I would think. It would be dangerous to provide a utility > > like shred if it doesn't know to error out for files in ZFS. > > > > So it should least be modified to be ZFS aware. Since ZFS might not be > > the only COW filesystem (think BSD 4.4 LFS) it may be a good idea to > > come up with a generic interface for querying whether writes to a file > > overwrite the same disk blocks or not. > > Well, this seems like an entree to make my economic point. We cannot > staff each OSS integration effort such that it could modify a > significant subset of commands (or the system) to meet policies and/or > advised changes on initial integration; the freeware team is at best > able to choose to ship or omit components. (This choice means that, > in some cases, dependencies will not be satisfied that might have been > satisfied on other systems.) If an incoming set of bug > reports/customer calls implies that additional investment is > justified, then that team will have to come back to declare their new > proposed interfaces. Then, IMO the fact that GNU shred(1) does not work on ZFS files should result in: - omission of shred from this case - filing bugs against GNU shred to recognize ZFS and other COW filesystems - when GNU shred is so improved it could be added to Solaris then - an RFE for an interface to ask the system whether writes to a file overwrite its blocks, or to request that writes to a file overwrite its blocks (the latter seems more robust, and ZFS would always reject it) Nico -- From scott.rotondo@sun.com Tue Jan 23 16:20:50 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0O0Kn5C010057 for ; Tue, 23 Jan 2007 16:20:50 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0O0KlZp002633; Wed, 24 Jan 2007 00:20:49 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC00B0RJMMWW00@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jan 2007 16:20:46 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC00562JMM5Q50@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jan 2007 16:20:46 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0O0Kh6n025989; Tue, 23 Jan 2007 16:20:43 -0800 (PST) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l0O0KgP14531; Tue, 23 Jan 2007 16:20:42 -0800 (PST) Date: Tue, 23 Jan 2007 16:20:42 -0800 From: Scott Rotondo Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070123195335.GF27099@eng.sun.com> To: Stephen Hahn Cc: Nicolas Williams , Casper.Dik@sun.com, Darren J Moffat , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <45B6A65A.5070306@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> User-Agent: Mail/News 1.5.0.4 (X11/20060718) Status: RO Content-Length: 996 Stephen Hahn wrote: > Well, this seems like an entree to make my economic point. We cannot > staff each OSS integration effort such that it could modify a > significant subset of commands (or the system) to meet policies and/or > advised changes on initial integration; the freeware team is at best > able to choose to ship or omit components. (This choice means that, > in some cases, dependencies will not be satisfied that might have been > satisfied on other systems.) If an incoming set of bug > reports/customer calls implies that additional investment is > justified, then that team will have to come back to declare their new > proposed interfaces. Past experience with Sun project teams overwhelmingly shows that code changes deferred at initial integration are almost never completed later. We could choose to apply a different standard to OSS components, but we shouldn't assume that they will become more compliant with Solaris policies over time. Scott From sch@rosseau.sfbay.sun.com Tue Jan 23 17:41:27 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0O1fQeX012153 for ; Tue, 23 Jan 2007 17:41:27 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0O1fNG7018134; Wed, 24 Jan 2007 01:41:26 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC00101ND00M00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 17:41:24 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC00IXOND0FN70@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 17:41:24 -0800 (PST) Received: from rosseau.sfbay.sun.com (rosseau.SFBay.Sun.COM [129.146.228.252]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0O1fLaP014676; Tue, 23 Jan 2007 17:41:21 -0800 (PST) Received: from rosseau.sfbay.sun.com (localhost [127.0.0.1]) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0O1fLdb027557; Tue, 23 Jan 2007 17:41:21 -0800 (PST) Received: (from sch@localhost) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l0O1fLpe027556; Tue, 23 Jan 2007 17:41:21 -0800 (PST) Date: Tue, 23 Jan 2007 17:41:21 -0800 From: Stephen Hahn Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B6A65A.5070306@sun.com> To: Scott Rotondo Cc: Nicolas Williams , Casper.Dik@sun.com, Darren J Moffat , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <20070124014120.GC27358@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1772 * Scott Rotondo [2007-01-23 16:20]: > Stephen Hahn wrote: > > Well, this seems like an entree to make my economic point. We cannot > > staff each OSS integration effort such that it could modify a > > significant subset of commands (or the system) to meet policies and/or > > advised changes on initial integration; the freeware team is at best > > able to choose to ship or omit components. (This choice means that, > > in some cases, dependencies will not be satisfied that might have been > > satisfied on other systems.) If an incoming set of bug > > reports/customer calls implies that additional investment is > > justified, then that team will have to come back to declare their new > > proposed interfaces. > > Past experience with Sun project teams overwhelmingly shows that code > changes deferred at initial integration are almost never completed > later. We could choose to apply a different standard to OSS components, > but we shouldn't assume that they will become more compliant with > Solaris policies over time. There aren't any surprises here. I am explicitly saying that the freeware team, as initial integrator, is going to do very little in terms of code changes that would deviate from the upstream community and is only going to omit components that violate those policies that are still applicable. If another group of interested individuals wished to work with the upstream community to adopt changes, then approach to increasing compliance is more likely. (X11 and GNOME, to me, appear to be demonstrating that this is the only sensible way to work.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn@sun.com http://blogs.sun.com/sch/ From fielding@gbiv.com Tue Jan 23 17:43:19 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0O1hJPd012190 for ; Tue, 23 Jan 2007 17:43:19 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0O1hJCn018386; Tue, 23 Jan 2007 17:43:19 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC00101NG76O00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 17:43:19 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC00IEING6FN80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 17:43:18 -0800 (PST) Received: from relay3.sun.com (relay3.sun.com [150.143.103.54] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0O04bDJ014694; Tue, 23 Jan 2007 18:43:18 -0700 (MST) Received: from mms03es.sun.com ([150.143.104.54] [150.143.104.54]) by relay3.sun.com with ESMTP; Wed, 24 Jan 2007 01:43:15 +0000 (Z) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14]) by mms03es.sun.com with ESMTP; Wed, 24 Jan 2007 01:43:14 +0000 (Z) Received: from scorpio.lunarpages.com ([209.200.229.70] [209.200.229.70]) by relay1.sun.com with ESMTP; Wed, 24 Jan 2007 01:43:14 +0000 (Z) Received: from wsip-70-183-62-251.oc.oc.cox.net ([70.183.62.251] helo=[10.2.8.55]) by scorpio.lunarpages.com with esmtpa (Exim 4.52) id 1H9XAQ-0005wD-GK; Tue, 23 Jan 2007 17:43:14 -0800 Date: Tue, 23 Jan 2007 17:43:10 -0800 From: "Roy T. Fielding" Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B6A65A.5070306@sun.com> To: Scott Rotondo Cc: Stephen Hahn , PSARC-EXT@sun.com Message-id: <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - sun.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com X-Source: X-Source-Args: X-Source-Dir: References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> Status: RO Content-Length: 2842 Stephen Hahn wrote: > Well, this seems like an entree to make my economic point. We > cannot > staff each OSS integration effort such that it could modify a > significant subset of commands (or the system) to meet policies > and/or > advised changes on initial integration; the freeware team is at best > able to choose to ship or omit components. I will add that the authors of the open source software do not want redistributors to make independent changes to their code aside from the minimum necessary to compile the code on a new platform. The authors end up having to deal with the issues that are created when misinformed changes are made to their code. If there are bits of Solaris policy that would be enhanced by an alternative implementation within an OSS project, then the change requests can be sent upstream. Changes based on sensible policies (i.e., those that reduce complexity or improve performance) are usually adopted even when they are platform-specific. I think the ARC should understand that attempting to pick and choose from open source alternatives while making changes to those products is not a feasible course of action. It is okay to do what the case suggests and install the original OSS product in a location that can be selectively included in paths. It is also okay to take an OSS product, rename the product and all of the interfaces, and then place whatever constraints you want on that new product. At worst, that will only waste developer time on the fork and Sun's customers can download the real product from the source. It is not okay to pretend to integrate someone else's product, including their names, while not actually doing so. That results in costing the original developers' time and reputation. Apache would consider it a trade name violation. I hear a lot about Solaris policies and how so-and-so would violate some ancient criterion learned from the olden days (invariably, the ones involving Solaris 1-2 transition history). I don't hear much about the goal of improving Solaris as a platform so that non-Sun developers will consider actively supporting it again. The benefits of having built-in support for GNU coreutils should be weighed against the cost of duplicating some features in the overall operating system. I think it is a clear win, even if it would increase the cost of export checks or FIPS compliance (which I highly doubt given the legal-centric nature of those processes). In short, I agree with Stephen's assessment that, given the potential technical conflicts have been addressed by the case, the remaining decision is economic in nature: does Solaris want to tradeoff the benefit of having a working coreutils versus the cost of duplicate code? Cheers, Roy T. Fielding OpenSolaris CAB From David.Comay@sun.com Tue Jan 23 18:20:19 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0O2KHL3012941 for ; Tue, 23 Jan 2007 18:20:18 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0O2KCIl025032; Wed, 24 Jan 2007 02:20:16 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC00K03P5QWY00@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jan 2007 18:20:14 -0800 (PST) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC005O8P5Q5TA0@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jan 2007 18:20:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id l0O2JlDC002209; Tue, 23 Jan 2007 18:19:56 -0800 (PST) Date: Tue, 23 Jan 2007 18:19:47 -0800 (PST) From: David.Comay@sun.com Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <1169513743.28083.74.camel@thunk> Sender: comay@izimbra.SFBay.Sun.COM To: Bill Sommerfeld Cc: Stephen Hahn , PSARC-EXT@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <20070123002859.GI24874@eng.sun.com> <1169513743.28083.74.camel@thunk> Status: RO Content-Length: 1276 > I don't see this as an acceptable resolution; programs or scripts > written to depend on coreutils may not run unless we supply these > utilities. Isn't this true, though, of the omission of any component from coreutils? It's likely there are fewer programs that depend on coreutils' "su" or or even "shred" but we face the same issue with leaving those programs out as well. I don't know whether the LSB "standard" covers any of these components but in the absence of a GNU standards compliance requirement for OpenSolaris, it seems omitting certain items from coreutils is reasonable if not unavoidable (eg, for the security issues mentioned earlier.) In any case, I assume the unaltered GNU *sum utilities could still be shipped in /usr/gnu/bin even if the "native" ones proposed in PSARC/2005/530 were delivered in /usr/bin so a script requiring the coreutils' version would need to augment their PATH accordingly. (That said, I'm still uncomfortable with a ARC case that has reserved the name-space but not actually integrated anything preventing other projects from integrating an alternate implementation. Perhaps it just means that PSARC/2005/530 needs a follow-on case to include whatever changes necessary to be able to replace the coreutils versions.) dsc From nw141292@binky.Central.Sun.COM Tue Jan 23 22:15:01 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0O6F00Y016854 for ; Tue, 23 Jan 2007 22:15:00 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0O6Es0O009078; Wed, 24 Jan 2007 06:14:57 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCD0060500VYK00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 22:14:55 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCD00F7L00VYG50@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 22:14:55 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0O6ESG0014839; Wed, 24 Jan 2007 00:14:28 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0O6ESnK014838; Wed, 24 Jan 2007 00:14:28 -0600 (CST) Date: Wed, 24 Jan 2007 00:14:28 -0600 From: Nicolas Williams Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070124014120.GC27358@eng.sun.com> To: Stephen Hahn Cc: Scott Rotondo , Casper.Dik@sun.com, Darren J Moffat , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <20070124061427.GP12135@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <20070124014120.GC27358@eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 222 I would expect at the very least a bug to be filed against GNU shred(1) to recognize COW filesystems and the Solaris manpage for it to warn loudly that it doesn't work on ZFS. Surely the maintainers will want that fixed. From gww@eng.sun.com Tue Jan 23 22:58:38 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0O6wcHo017589 for ; Tue, 23 Jan 2007 22:58:38 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0O6wWLP016473 for <@sunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Wed, 24 Jan 2007 06:58:37 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCD0030V21O7600@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 23 Jan 2007 23:58:36 -0700 (MST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCD00FWL21NP840@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 23 Jan 2007 23:58:35 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0O6wZIL004296; Tue, 23 Jan 2007 22:58:35 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0O6wtne023359; Tue, 23 Jan 2007 22:58:55 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l0O6wt1t023358; Tue, 23 Jan 2007 22:58:55 -0800 (PST) Date: Tue, 23 Jan 2007 22:58:55 -0800 (PST) From: Gary Winiger Subject: Re: 2007/048 Include GNU coreutils 6.4 To: PSARC-EXT@sun.com, sch@eng.sun.com Message-id: <200701240658.l0O6wt1t023358@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1603 > I am sponsoring the following fast track for myself. It seeks Minor Again, anything that wouldn't qualify for a Patch release binding? > release binding and is set to timeout on 31 January. The appendix > contains all of the command synopses for the various coreutils > commands. > > (Typo warning: this case has an appendix to follow; 2007/407 does ^^^ typo ;-) > not.) > Location Uncommitted > Invocation Uncommitted > Human-readable output Volatile ^^^^^^^^ I thought we had "Not an Interface" that would be a better choice to discourage scripting of human readable output. Is there some reason to not choose "Not an Interface"? > md5sum > sha1sum > sha224sum > sha256sum > sha384sum > sha512sum I'd like to express my concerns here in addition to the other's already mentioned. While I completely understand not forking from the FOSS versions except to build in the Solaris environment, I'm concerned that not using the Solaris optimized algorithms will be a dissatisfier. I'm also concerned about what appears to be a future Solaris evaluation requirement. See PSARC/2007/016 Medimum Robustness PP for audit of cryptographic function failure. I've recently been working off line with some of the Crypto project team to investigate these requirements more fully and provide for adding audit to the various crypto utilities. Perhaps /usr/gnu/* would be excluded from any evaluation. Again I think that could be a dissatifier. In general all of what ships as core Solaris meets evaluation criteria. Gary.. From Darren.Moffat@Sun.COM Wed Jan 24 01:44:41 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0O9ie55020829 for ; Wed, 24 Jan 2007 01:44:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0O9ietm026179; Wed, 24 Jan 2007 01:44:40 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCD00L0D9QGIS00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 01:44:40 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCD00F2N9QDYYB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 01:44:38 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0O9ib9b028925; Wed, 24 Jan 2007 09:44:37 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCD00C019OFX400@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 24 Jan 2007 09:44:36 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCD004OD9QBK800@d1-emea-09.sun.com>; Wed, 24 Jan 2007 09:44:36 +0000 (GMT) Date: Wed, 24 Jan 2007 09:44:35 +0000 From: Darren J Moffat Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070123194255.GA27140@eng.sun.com> Sender: Darren.Moffat@Sun.COM To: Stephen Hahn Cc: Casper.Dik@Sun.COM, Bill Sommerfeld , PSARC-EXT@Sun.COM Message-id: <45B72A83.5030905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194255.GA27140@eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061128) Status: RO Content-Length: 1415 Stephen Hahn wrote: >> Isn't it the case that schred does not work on ZFS so why provide >> it at all? > > Yes, shred won't work on ZFS. Bill and Dan were just telling me that > snapshots mean it can never really work, so it's probably best to drop > it. There are various actions the ZFS team might take to decrease > unintended data recovery, but shred isn't equivalent to any of them. > > I suppose the question is whether the command should be modified to > warn about "failure to shred on this filesystem", or simply dropped. Personally I think it should be dropped. It isn't just local file systems like ZFS that are a problem, consider if you are on an NFS client and the server is using a COW filesystem it still won't work and you on the client have no way to know this (eg a NetApp box or a Solaris machine exporting a ZFS file system over NFS). There has recently been a long discussion on the opensolaris zfs-discuss/security-discuss aliases recently (started by me) about providing "shred"-like functionality as a core part of the filesystem. http://www.opensolaris.org/jive/thread.jspa?threadID=20438&tstart=0 IMO shred as it appears in GNU coreutils is down right dangerous because it leads end users into a false sense of security and they need to know a huge amount of info about not only which filesystem they are using but how it is implemented. -- Darren J Moffat From schilling@fokus.fraunhofer.de Wed Jan 24 02:55:24 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OAtOHP022116 for ; Wed, 24 Jan 2007 02:55:24 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0OAtLp0006074; Wed, 24 Jan 2007 02:55:23 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCD0090XD0B5H00@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 03:55:23 -0700 (MST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCD001JWD024T80@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 03:55:20 -0700 (MST) Received: from relay24.sun.com (ip192-12-251-74.block6.us.syntegra.com [192.12.251.74]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l0OAtDiG029904; Wed, 24 Jan 2007 02:55:13 -0800 (PST) Received: from mms24es.sun.com ([150.143.232.74] [150.143.232.74]) by relay24.sun.com with ESMTP; Wed, 24 Jan 2007 10:55:13 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms24es.sun.com with ESMTP; Wed, 24 Jan 2007 10:55:12 +0000 (Z) Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14] [193.174.154.14]) by relay22.sun.com with ESMTP; Wed, 24 Jan 2007 10:55:12 +0000 (Z) Received: from burner.fokus.fraunhofer.de (burner [10.147.65.166]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id l0OAt6911778; Wed, 24 Jan 2007 11:55:06 +0100 (MET) Received: (from jes@localhost) by burner.fokus.fraunhofer.de (8.12.9+Sun/8.12.9/Submit) id l0OArAD1010748; Wed, 24 Jan 2007 11:53:10 +0100 (CET) Date: Wed, 24 Jan 2007 11:53:10 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> Sender: schilling@fokus.fraunhofer.de To: scott.rotondo@sun.com, fielding@gbiv.com Cc: PSARC-EXT@sun.com Message-id: <45b73a96.dRIpHJ6waK485SoX%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> User-Agent: nail 11.22 3/20/05 Status: RO Content-Length: 1703 "Roy T. Fielding" wrote: ... I agree with your (unquoted) text above, this is where Debian is currently disgusting developers. I hope that Sun will not follow this idea... > In short, I agree with Stephen's assessment that, given the > potential technical conflicts have been addressed by the case, > the remaining decision is economic in nature: does Solaris want > to tradeoff the benefit of having a working coreutils versus > the cost of duplicate code? I am not sure what you like to see... I would neither like to see Solaris core util sources appear in favor of ksh's libcmd nor would I like to see something similar wo happen with GNU coreutils. We have a good (and POSIX approved) set of utils available under a free license this is something we should not give up without a reason. I personally don't believe that we attract more developers by including more GNU utils or by replacing UNIX tools by GNU tools. It did take a long time to let developers go away from Solaris and it will take a similar time to get them back. This will happen because OpenSolaris is an attractive platform already and not because of some marketing effects. You cannot enforce this to happen faster and you need to wait until less FUD against OpenSolaris is spread. I believe that the best way of trying to get more Developers back fater would be by trying to work against the FUD. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From carlsonj@phorcys.east.sun.com Wed Jan 24 04:04:51 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OC4oEm022970 for ; Wed, 24 Jan 2007 04:04:50 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0OC4XpS008612; Wed, 24 Jan 2007 20:04:46 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCD00009G7TSX00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 04:04:41 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCD00M0DG7SA130@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 04:04:40 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0OC4eSv019910; Wed, 24 Jan 2007 07:04:40 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0OC4dr5019907; Wed, 24 Jan 2007 07:04:40 -0500 (EST) Date: Wed, 24 Jan 2007 07:04:39 -0500 From: James Carlson Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> To: "Roy T. Fielding" Cc: Scott Rotondo , PSARC-EXT@sun.com Message-id: <17847.19287.737668.625722@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> Status: RO Content-Length: 1931 Roy T. Fielding writes: > I think the ARC should understand that attempting to pick > and choose from open source alternatives while making changes to > those products is not a feasible course of action. It is okay to do I think the project team should understand that ARC members not only understand these issues, but many of them are also themselves contributors to and maintainers of external open source software, and have been for many years. We didn't just collectively fall off the turnip truck. (In my case, yes, I've seen horrible problems on certain Linux platforms because of the misguided ways in which the distributors choose to hack at the PPP code. The solution to many problems is to rip out the hacked vendor code and replace with the original distribution. It's certainly not an unknown problem.) In this case, we're talking about system architecture. How that actually gets designed, implemented, and managed is the project team's responsibility. In other words, if we were to find that using the common crypto routines was a requirement for operation on Solaris (I don't think that's happened, but it's one of the issues being discussed), then it's up to the project team to determine what to do about that. Yes, forking might be a bad decision on their part. They'd likely be in better shape overall if they can contribute the changes back to the upstream repository. I don't believe it's acceptable to have shackles applied to system architecture. It's not reasonable to say that because some arbitrary developer somewhere in the GNU universe thought that "Foo" was a good idea, then Solaris _must_ also believe the same thing. Doing so is abdicating our responsibility. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sommerfeld@sun.com Wed Jan 24 06:19:34 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OEJO8I024703 for ; Wed, 24 Jan 2007 06:19:34 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0OEJA6w011161; Wed, 24 Jan 2007 14:19:13 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCD0011BMFZRV00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 06:19:11 -0800 (PST) Received: from localhost.east.sun.com ([129.148.19.3]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCD00G2JMFYYJ50@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 06:19:11 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0OEINXk006416; Wed, 24 Jan 2007 14:18:23 +0000 (GMT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0OEIJPq006415; Wed, 24 Jan 2007 09:18:19 -0500 (EST) Date: Wed, 24 Jan 2007 09:18:18 -0500 From: Bill Sommerfeld Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B72A83.5030905@Sun.COM> To: Darren J Moffat Cc: Stephen Hahn , Casper.Dik@sun.com, PSARC-EXT@sun.com Message-id: <1169648298.6401.12.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.6.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194255.GA27140@eng.sun.com> <45B72A83.5030905@Sun.COM> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 1051 On Wed, 2007-01-24 at 09:44 +0000, Darren J Moffat wrote: > IMO shred as it appears in GNU coreutils is down right dangerous because > it leads end users into a false sense of security and they need to know > a huge amount of info about not only which filesystem they are using but > how it is implemented. It appears that the usage message and associated documentation for shred already includes significant cautions of that form (I've looked at a copy on the SWAN which identifies itself as version 5.0); the help message in 5.0 also says: The default is not to remove the files because it is common to operate on device files like /dev/hda, and those files usually should not be removed. which suggests that the intended use is for devices, not files. I think the appropriate action is to ensure the documentation and messages are accurate rather than to remove it. At a higher level I'm uncomfortable with the notion that we can say we're integrating GNU coreutils if we're not providing the whole command set. - Bill From sommerfeld@sun.com Wed Jan 24 07:37:33 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OFbXnK026536 for ; Wed, 24 Jan 2007 07:37:33 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0OFbXW20032; Wed, 24 Jan 2007 08:37:33 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCD00H0LQ2KY100@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 08:37:32 -0700 (MST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCD00C0MQ2J2CD0@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 08:37:31 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0OFbSFv011544; Wed, 24 Jan 2007 10:37:28 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0OFbSe4012800; Wed, 24 Jan 2007 10:37:28 -0500 (EST) Date: Wed, 24 Jan 2007 10:37:28 -0500 From: Bill Sommerfeld Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070123191144.GD27099@eng.sun.com> To: Stephen Hahn Cc: Darren J Moffat , PSARC-EXT@sun.com Message-id: <1169653048.12336.18.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> Status: RO Content-Length: 1228 On Tue, 2007-01-23 at 11:11 -0800, Stephen Hahn wrote: > That bring us to two choices for sha*sum: There are more than two possible choices here. > A. These commands will be withdrawn from this case. As far as I > can see, the appropriate steps are: > > 1. File RFE against libmd5 for the new *_stream() interfaces. > > 2. Make upstream code corrections to sha*sum. > > 3. Await release of coreutils version with changes accepted. > > 4. File supplementary case, advertising inclusion of > additional commands. As there are no caller-visible interface changes to the commands I don't see any reason to hold off on integration until the changes are accepted by the upstream maintainer. > B. The commands will be provided, with requirements that > > 1. "Non-FIPS" disclaimer text will be added to required > manual pages. I believe this has an unacceptable risk of creating FUD both about our level of commitment to FIPS compliance and support of the GNU core utils; it is also (IMHO) more work than fixing sha*sum to use libmd. > (shred is already en route to handling similar to B. I don't believe this is an appropriate response. From jek3@sun.com Wed Jan 24 13:54:34 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OLsX1Z011630 for ; Wed, 24 Jan 2007 13:54:33 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0OLsHVK008974; Wed, 24 Jan 2007 21:54:29 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE00F0J7IRBK00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 13:54:27 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.58.37]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE001AC7IPSH60@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 13:54:25 -0800 (PST) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0OLsNdb975339; Wed, 24 Jan 2007 13:54:24 -0800 (PST) Date: Wed, 24 Jan 2007 11:52:42 -1000 From: Joseph Kowalski Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070124014120.GC27358@eng.sun.com> To: Stephen Hahn Cc: Scott Rotondo , Nicolas Williams , Casper.Dik@sun.com, Darren J Moffat , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <45B7D52A.1060001@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <20070124014120.GC27358@eng.sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 625 I hope I'm not throwing down a glove here. There has been a lot of posturing about having various FOSS bits conforming to various policies. For the most part, there are good points on either side. However, I want to assert two things: 1) There is *no* justification for exceptions to the security policy. 2) There are precedents for many policies, such as those associated with the CLIP/getopt stuff. If we aren't going to conform to those policies here, because we think we have a better policy or a formal exception set we need to officially state the amendment to the policy. - jek3 From sch@rosseau.sfbay.sun.com Wed Jan 24 14:08:20 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OM8J8I011996 for ; Wed, 24 Jan 2007 14:08:19 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0OM7bWe012758; Wed, 24 Jan 2007 22:08:17 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE00H0985PKZ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 14:08:13 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE001DO85OSH70@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 14:08:12 -0800 (PST) Received: from rosseau.sfbay.sun.com (rosseau.SFBay.Sun.COM [129.146.228.252]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0OM89DR027785; Wed, 24 Jan 2007 14:08:09 -0800 (PST) Received: from rosseau.sfbay.sun.com (localhost [127.0.0.1]) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0OM89v6017481; Wed, 24 Jan 2007 14:08:09 -0800 (PST) Received: (from sch@localhost) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l0OM89VD017480; Wed, 24 Jan 2007 14:08:09 -0800 (PST) Date: Wed, 24 Jan 2007 14:08:09 -0800 From: Stephen Hahn Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B7D52A.1060001@sun.com> To: Joseph Kowalski Cc: Scott Rotondo , Nicolas Williams , Casper.Dik@sun.com, Darren J Moffat , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <20070124220809.GD17316@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <20070124014120.GC27358@eng.sun.com> <45B7D52A.1060001@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1855 * Joseph Kowalski [2007-01-24 13:54]: > > I hope I'm not throwing down a glove here. > > There has been a lot of posturing about having various FOSS bits > conforming to various policies. > For the most part, there are good points on either side. > > However, I want to assert two things: > > 1) There is *no* justification for exceptions to the security policy. Various out-of-band conversations are working through ways to separate and resolve the various policies involved. The proposal already met the requirements of the no-third-party-setuid policy; we're now examining the difficulties around cryptographic consumers. > 2) There are precedents for many policies, such as those > associated with the CLIP/getopt stuff. If we aren't going to > conform to those policies here, because we think we have a better > policy or a formal exception set we need to officially state the > amendment to the policy. Makes sense; is there a good catalogue of applicable policies? (I think the CLIP one is already sensible about incoming OSS.) It seems to me that we have an adjustable scale of "burdenedness" for each policy, between primarily primarily initial <---------------------> expert integrator community For security, it's absolutely to the left. For cryptography, likely to the left as well (although I'd like to see the cryptography-oriented members of the Security Community actively get OSS using better OpenSolaris interfaces now, rather than deferring to a hypothetical future integration.) For other policies, it's less clear that initial integration should be made so heavyweight. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn@sun.com http://blogs.sun.com/sch/ From alan.coopersmith@sun.com Wed Jan 24 14:15:56 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OMFtsT012188 for ; Wed, 24 Jan 2007 14:15:55 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0OMFpU1015196; Wed, 24 Jan 2007 22:15:53 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE00C0B8IFTX00@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 15:15:51 -0700 (MST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE00BRC8IE1600@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 15:15:50 -0700 (MST) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0OMFk5l013934; Wed, 24 Jan 2007 14:15:47 -0800 (PST) Date: Wed, 24 Jan 2007 14:15:46 -0800 From: Alan Coopersmith Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070124220809.GD17316@eng.sun.com> To: Stephen Hahn Cc: Joseph Kowalski , Scott Rotondo , Nicolas Williams , Casper.Dik@sun.com, Darren J Moffat , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <45B7DA92.9040903@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <20070124014120.GC27358@eng.sun.com> <45B7D52A.1060001@sun.com> <20070124220809.GD17316@eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 377 Stephen Hahn wrote: > Various out-of-band conversations are working through ways to > separate and resolve the various policies involved. The proposal > already met the requirements of the no-third-party-setuid policy; What no-third-party-setuid policy? -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sommerfeld@sun.com Wed Jan 24 14:21:15 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OMLFD6012355 for ; Wed, 24 Jan 2007 14:21:15 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0OMLEKY029255; Wed, 24 Jan 2007 14:21:15 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE00G0J8RE2N00@nwk-avmta-2.sfbay.sun.com>; Wed, 24 Jan 2007 14:21:14 -0800 (PST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE007P58RDUQ30@nwk-avmta-2.sfbay.sun.com>; Wed, 24 Jan 2007 14:21:14 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0OML9Rq023412; Wed, 24 Jan 2007 17:21:09 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0OML9ge014793; Wed, 24 Jan 2007 17:21:09 -0500 (EST) Date: Wed, 24 Jan 2007 17:21:08 -0500 From: Bill Sommerfeld Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070124220809.GD17316@eng.sun.com> To: Stephen Hahn Cc: Joseph Kowalski , Scott Rotondo , Nicolas Williams , Casper.Dik@sun.com, Darren J Moffat , PSARC-EXT@sun.com Message-id: <1169677268.12336.64.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <20070124014120.GC27358@eng.sun.com> <45B7D52A.1060001@sun.com> <20070124220809.GD17316@eng.sun.com> Status: RO Content-Length: 270 On Wed, 2007-01-24 at 14:08 -0800, Stephen Hahn wrote: > The proposal already met the requirements of the no-third-party-setuid policy; there is no such policy. please don't make your and our job more difficult by inventing additional policies for us to enforce. From sch@rosseau.sfbay.sun.com Wed Jan 24 14:30:21 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OMULiL012739 for ; Wed, 24 Jan 2007 14:30:21 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0OMUKW29968; Wed, 24 Jan 2007 15:30:20 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE00L0J96I5W00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 14:30:18 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE001BL96ISS80@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 14:30:18 -0800 (PST) Received: from rosseau.sfbay.sun.com (rosseau.SFBay.Sun.COM [129.146.228.252]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0OMUF2Q020330; Wed, 24 Jan 2007 14:30:15 -0800 (PST) Received: from rosseau.sfbay.sun.com (localhost [127.0.0.1]) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0OMUF5C017512; Wed, 24 Jan 2007 14:30:15 -0800 (PST) Received: (from sch@localhost) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l0OMUERW017511; Wed, 24 Jan 2007 14:30:14 -0800 (PST) Date: Wed, 24 Jan 2007 14:30:14 -0800 From: Stephen Hahn Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <1169677268.12336.64.camel@thunk> To: Bill Sommerfeld Cc: Joseph Kowalski , Scott Rotondo , Nicolas Williams , Casper.Dik@sun.com, Darren J Moffat , PSARC-EXT@sun.com Message-id: <20070124223014.GF17316@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <20070124014120.GC27358@eng.sun.com> <45B7D52A.1060001@sun.com> <20070124220809.GD17316@eng.sun.com> <1169677268.12336.64.camel@thunk> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 613 * Bill Sommerfeld [2007-01-24 14:21]: > On Wed, 2007-01-24 at 14:08 -0800, Stephen Hahn wrote: > > The proposal already met the requirements of the no-third-party-setuid policy; > > there is no such policy. please don't make your and our job more > difficult by inventing additional policies for us to enforce. I have obviously misquoted something I thought I understood. I'll go and find out what I thought I meant (or something like that). Sorry. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn@sun.com http://blogs.sun.com/sch/ From sommerfeld@sun.com Wed Jan 24 14:53:27 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OMrRMh013349 for ; Wed, 24 Jan 2007 14:53:27 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0OMrQhC005096; Wed, 24 Jan 2007 14:53:27 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE0010HA92UP00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 14:53:26 -0800 (PST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE00159A90SHC0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 14:53:25 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0OMrKNY000044; Wed, 24 Jan 2007 17:53:20 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0OMrJnR014943; Wed, 24 Jan 2007 17:53:20 -0500 (EST) Date: Wed, 24 Jan 2007 17:53:18 -0500 From: Bill Sommerfeld Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070124223014.GF17316@eng.sun.com> To: Stephen Hahn Cc: Joseph Kowalski , Scott Rotondo , Nicolas Williams , Casper.Dik@sun.com, Darren J Moffat , PSARC-EXT@sun.com Message-id: <1169679198.12336.83.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <20070124014120.GC27358@eng.sun.com> <45B7D52A.1060001@sun.com> <20070124220809.GD17316@eng.sun.com> <1169677268.12336.64.camel@thunk> <20070124223014.GF17316@eng.sun.com> Status: RO Content-Length: 870 On Wed, 2007-01-24 at 14:30 -0800, Stephen Hahn wrote: > * Bill Sommerfeld [2007-01-24 14:21]: > > On Wed, 2007-01-24 at 14:08 -0800, Stephen Hahn wrote: > > > The proposal already met the requirements of the no-third-party-setuid policy; > > > > there is no such policy. please don't make your and our job more > > difficult by inventing additional policies for us to enforce. > > I have obviously misquoted something I thought I understood. I'll go > and find out what I thought I meant (or something like that). You probably want to look at: http://sac.eng/cgi-bin/bp.cgi?NAME=PAM.bp "PAM provides a set of interfaces that all Solaris programs which do user identification and authentication, or re-authentication, or user session establishment, or user password change of Solaris user accounts are required to use." - Bill From jek3@sun.com Wed Jan 24 15:00:32 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0ON0WMB013765 for ; Wed, 24 Jan 2007 15:00:32 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0ON0TrJ006829; Wed, 24 Jan 2007 15:00:30 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE00H61AKTMT00@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 16:00:29 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE00B0LAKO1330@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 16:00:25 -0700 (MST) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0ON0M2x997589; Wed, 24 Jan 2007 15:00:22 -0800 (PST) Date: Wed, 24 Jan 2007 12:58:36 -1000 From: Joseph Kowalski Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <1169677268.12336.64.camel@thunk> To: Bill Sommerfeld Cc: Stephen Hahn , Scott Rotondo , Nicolas Williams , Casper.Dik@sun.com, Darren J Moffat , PSARC-EXT@sun.com Message-id: <45B7E49C.8020209@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <20070124014120.GC27358@eng.sun.com> <45B7D52A.1060001@sun.com> <20070124220809.GD17316@eng.sun.com> <1169677268.12336.64.camel@thunk> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 712 Bill Sommerfeld wrote: > On Wed, 2007-01-24 at 14:08 -0800, Stephen Hahn wrote: > >> The proposal already met the requirements of the no-third-party-setuid policy; >> > > there is no such policy. please don't make your and our job more > difficult by inventing additional policies for us to enforce. > Just to come to Stephen's defense, there was an example here. I'm hazy on the details, but I recall pushing back very hard on a proposed integration of a suid utility (one such utility in a proposed integration of many). I *think* I lost that argument. Anyway, policy or not, there is precedence to show that proposing the integration of a FOSS suid utility will bring discussion. - jek3 From scott.rotondo@sun.com Wed Jan 24 15:03:45 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0ON3jUn013818 for ; Wed, 24 Jan 2007 15:03:45 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0ON3hn9007798; Wed, 24 Jan 2007 15:03:44 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE00I0JAQ89000@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 16:03:44 -0700 (MST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE00B1CAQ71930@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 16:03:43 -0700 (MST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0ON3etL006598; Wed, 24 Jan 2007 15:03:40 -0800 (PST) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l0ON3eP25989; Wed, 24 Jan 2007 15:03:40 -0800 (PST) Date: Wed, 24 Jan 2007 15:03:40 -0800 From: Scott Rotondo Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B7E49C.8020209@sun.com> To: Joseph Kowalski Cc: Bill Sommerfeld , Stephen Hahn , Nicolas Williams , Casper.Dik@sun.com, Darren J Moffat , PSARC-EXT@sun.com Message-id: <45B7E5CC.60908@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <20070124014120.GC27358@eng.sun.com> <45B7D52A.1060001@sun.com> <20070124220809.GD17316@eng.sun.com> <1169677268.12336.64.camel@thunk> <45B7E49C.8020209@sun.com> User-Agent: Mail/News 1.5.0.4 (X11/20060718) Status: RO Content-Length: 233 Joseph Kowalski wrote: > Anyway, policy or not, there is precedence to show that proposing the > integration of a > FOSS suid utility will bring discussion. As will proposing a Sun-developed setuid utility (as it should). Scott From jek3@sun.com Wed Jan 24 15:10:56 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0ONAuir014022 for ; Wed, 24 Jan 2007 15:10:56 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0ONAqW09960; Wed, 24 Jan 2007 16:10:52 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE00J07B235F00@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 16:10:51 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.58.166]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE00BL7B211740@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 16:10:49 -0700 (MST) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0ONAmoL101850; Wed, 24 Jan 2007 15:10:48 -0800 (PST) Date: Wed, 24 Jan 2007 13:09:08 -1000 From: Joseph Kowalski Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B7E5CC.60908@sun.com> To: Scott Rotondo Cc: Bill Sommerfeld , Stephen Hahn , Nicolas Williams , Casper.Dik@sun.com, Darren J Moffat , PSARC-EXT@sun.com Message-id: <45B7E714.7030903@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <20070124014120.GC27358@eng.sun.com> <45B7D52A.1060001@sun.com> <20070124220809.GD17316@eng.sun.com> <1169677268.12336.64.camel@thunk> <45B7E49C.8020209@sun.com> <45B7E5CC.60908@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1022 Scott Rotondo wrote: > Joseph Kowalski wrote: > >> Anyway, policy or not, there is precedence to show that proposing the >> integration of a >> FOSS suid utility will bring discussion. > > As will proposing a Sun-developed setuid utility (as it should). > > Scott True enough. My view is that any suid utility needs to be treated as if it were a "Sun" or "OpenSolaris" developed utility in that it can't be integrated or updated without a complete code review or understanding of what it does. Its not that we shouldn't accept FOSS suid utilities, its just that all the integration expediencies usually associated with FOSS software don't apply. In the case I vaguely remember (wish I could remember the utility name), my view was that it was a marginally useful utility to begin with, so why should we take on this additional cost/risk. I lost the argument only because others viewed it as much more useful than I did. I think we all agreed on the cost - others just saw more benefit than I did. - jek3 From dduvall@zruty.sfbay.sun.com Wed Jan 24 15:18:57 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0ONIuGi014300 for ; Wed, 24 Jan 2007 15:18:56 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0ONIlWm003419; Wed, 24 Jan 2007 23:18:54 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE00K0FBFF4E00@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 16:18:51 -0700 (MST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE00B06BFE1650@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 16:18:51 -0700 (MST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0ONIlam013704; Wed, 24 Jan 2007 15:18:47 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0ONIlc4005861; Wed, 24 Jan 2007 15:18:47 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l0ONIlD3005860; Wed, 24 Jan 2007 15:18:47 -0800 (PST) Date: Wed, 24 Jan 2007 15:18:47 -0800 From: Danek Duvall Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B7E714.7030903@sun.com> To: Joseph Kowalski Cc: Scott Rotondo , Bill Sommerfeld , Stephen Hahn , Nicolas Williams , Casper.Dik@sun.com, Darren J Moffat , PSARC-EXT@sun.com Message-id: <20070124231847.GX23837@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <20070124014120.GC27358@eng.sun.com> <45B7D52A.1060001@sun.com> <20070124220809.GD17316@eng.sun.com> <1169677268.12336.64.camel@thunk> <45B7E49C.8020209@sun.com> <45B7E5CC.60908@sun.com> <45B7E714.7030903@sun.com> User-Agent: mutt-ng/devel-r535 (SunOS) Status: RO Content-Length: 762 On Wed, Jan 24, 2007 at 01:09:08PM -1000, Joseph Kowalski wrote: > In the case I vaguely remember (wish I could remember the utility name), > my view was that it was a marginally useful utility to begin with, so why > should we take on this additional cost/risk. I lost the argument only > because others viewed it as much more useful than I did. I think we all > agreed on the cost - others just saw more benefit than I did. Are you talking about sudo or screen, perhaps? I'm pretty sure you've raised one or both before as examples in previous meetings. But both are part of the Companion CD, and both are installed non-setuid, with instructions for the user to add that bit if desired, so they don't exactly match what you're talking about here. Danek From gww@eng.sun.com Wed Jan 24 15:49:59 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0ONnwgA014808 for ; Wed, 24 Jan 2007 15:49:58 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0ONnwXD010190; Wed, 24 Jan 2007 15:49:58 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE00A05CV9XX00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 15:49:57 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE001D2CV8SPE0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 15:49:56 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0ONnrCc015049; Wed, 24 Jan 2007 15:49:53 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0ONoExf024628; Wed, 24 Jan 2007 15:50:14 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l0ONoEPZ024627; Wed, 24 Jan 2007 15:50:14 -0800 (PST) Date: Wed, 24 Jan 2007 15:50:14 -0800 (PST) From: Gary Winiger Subject: Re: 2007/048 Include GNU coreutils 6.4 To: sommerfeld@sun.com, jek3@sun.com Cc: sch@eng.sun.com, scott.rotondo@sun.com, Nicolas.Williams@sun.com, Casper.Dik@sun.com, Darren.Moffat@sun.com, PSARC-EXT@sun.com Message-id: <200701242350.l0ONoEPZ024627@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1696 > >> The proposal already met the requirements of the no-third-party-setuid policy; > >> > > > > there is no such policy. please don't make your and our job more > > difficult by inventing additional policies for us to enforce. > > > Just to come to Stephen's defense, there was an example here. I'm hazy > on the details, but I > recall pushing back very hard on a proposed integration of a suid > utility (one such utility in a > proposed integration of many). I *think* I lost that argument. > > Anyway, policy or not, there is precedence to show that proposing the > integration of a > FOSS suid utility will bring discussion. I don't recall that any part of this proposal includes suid programs. Nor any part of this proposal (except for the codification of what /usr/gnu/* and friends) that I had particular issue with. I would point out the various precedences: PSARC/1999/555 Getting with the Freeware Program PSARC/2000/488 Solaris/Linux Commands Compatibility and PSARC/2005/185 Enabling serendipitous discovery And possibly other cases. And Policies: http://opensolaris.org/os/community/arc/policies/shared-sharable/ http://opensolaris.org/os/community/arc/policies/libraries/ http://opensolaris.org/os/community/arc/policies/SMF-policy/ http://opensolaris.org/os/community/arc/policies/NITS-policy/ http://opensolaris.org/os/community/arc/policies/PAM/ http://opensolaris.org/os/community/arc/policies/audit-policy/ And possibly other policies (such as something I'm hoping to clarify as the "Solaris Security Policy") That apply in general. I don't believe it's proper to to address any one without the context of the others. Gary.. From fielding@gbiv.com Wed Jan 24 17:41:36 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0P1fZhX016543 for ; Wed, 24 Jan 2007 17:41:36 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0P1fAkn028460; Thu, 25 Jan 2007 09:41:28 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE00701I12MX00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 17:41:26 -0800 (PST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE00IODI11I850@nwk-avmta-1.sfbay.Sun.COM>; Wed, 24 Jan 2007 17:41:25 -0800 (PST) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l0P1fLn3013862; Wed, 24 Jan 2007 17:41:25 -0800 (PST) Received: from mms28es.sun.com ([150.143.232.154] [150.143.232.154]) by relay23.sun.com with ESMTP; Thu, 25 Jan 2007 01:41:21 +0000 (Z) Received: from mms23bas.mms.us.syntegra.com (mms23bas.mms.us.syntegra.com [192.12.251.50]) by mms28es.sun.com with ESMTP; Thu, 25 Jan 2007 01:41:20 +0000 (Z) Received: from scorpio.lunarpages.com ([209.200.229.70] [209.200.229.70]) by relay23.sun.com with ESMTP; Thu, 25 Jan 2007 01:41:20 +0000 (Z) Received: from wsip-70-183-62-251.oc.oc.cox.net ([70.183.62.251] helo=[10.2.8.55]) by scorpio.lunarpages.com with esmtpa (Exim 4.52) id 1H9tc6-0007SB-Se; Wed, 24 Jan 2007 17:41:18 -0800 Date: Wed, 24 Jan 2007 17:41:17 -0800 From: "Roy T. Fielding" Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <17847.19287.737668.625722@gargle.gargle.HOWL> To: James Carlson Cc: Scott Rotondo , PSARC-EXT@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - sun.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com X-Source: X-Source-Args: X-Source-Dir: References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> <17847.19287.737668.625722@gargle.gargle.HOWL> Status: RO Content-Length: 4228 On Jan 24, 2007, at 4:04 AM, James Carlson wrote: > Roy T. Fielding writes: >> I think the ARC should understand that attempting to pick >> and choose from open source alternatives while making changes to >> those products is not a feasible course of action. It is okay to do > > I think the project team should understand that ARC members not only > understand these issues, but many of them are also themselves > contributors to and maintainers of external open source software, and > have been for many years. We didn't just collectively fall off the > turnip truck. > > (In my case, yes, I've seen horrible problems on certain Linux > platforms because of the misguided ways in which the distributors > choose to hack at the PPP code. The solution to many problems is to > rip out the hacked vendor code and replace with the original > distribution. It's certainly not an unknown problem.) > > In this case, we're talking about system architecture. How that > actually gets designed, implemented, and managed is the project team's > responsibility. I disagree. In this case (whether or not to change the coreutils to use a Solaris-specific system library), we are talking about application design regarding maintenance versus performance trade-offs. It is a decision that should be left to the original developers and it makes no economic sense to impose it on integration. > In other words, if we were to find that using the common crypto > routines was a requirement for operation on Solaris (I don't think > that's happened, but it's one of the issues being discussed), then > it's up to the project team to determine what to do about that. Yes, > forking might be a bad decision on their part. They'd likely be in > better shape overall if they can contribute the changes back to the > upstream repository. That is just imposing an internal design decision on a product because someone thinks they know better. In fact, they might know better, and it might indeed be the better choice, but it makes no difference whatsoever to the architecture of the proposal or of the system as a whole. Calling it an architecture decision is just an excuse. One-way hash algorithms are not cryptography and are not subject to the same export controls as two-way encryption. They are occasionally subject to FIPS when used within an encryption or authentication product, but that has nothing whatsoever to do with the utilities under discussion (file digesters). If Solaris already had utilities with the same names, interfaces, and functionality, then it would make sense to exclude the gnu ones. It would also make sense for a new project to create such tools using libmd, or to submit patches upstream to coreutils such that they would selectively make use of the operating system's supplied routines when available (assuming they don't already, which I haven't checked). What doesn't make sense is to create a barrier to entry for an *alternative* development environment based on an internal design decision over which library is used to supply an implementation. The only reason why this environment is needed is because the rest of the world did not follow the same implementation decisions as Solaris. If "do it our way" was a rational response, Solaris users wouldn't need these utilities at all. > I don't believe it's acceptable to have shackles applied to system > architecture. It's not reasonable to say that because some arbitrary > developer somewhere in the GNU universe thought that "Foo" was a good > idea, then Solaris _must_ also believe the same thing. Doing so is > abdicating our responsibility. No. The choice in that situation, were it ever to occur, is to simply not redistribute the technology. The premise here is that there exists a reason for distributing an overlay tools environment that behaves according to the GNU toolset. If doing that would violate some Solaris policy, then don't do it -- write your own tools. In this case, I don't know of any policy that applies to the constraints that have been mentioned so far. No such policy is documented on opensolaris.org. ....Roy From jek3@sun.com Wed Jan 24 21:35:30 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0P5ZTdh019391 for ; Wed, 24 Jan 2007 21:35:30 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0P5ZNa0016763; Thu, 25 Jan 2007 05:35:26 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCE00F0BSV0PE00@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 22:35:24 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.68.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCE00BAGSUZLX70@brm-avmta-1.central.sun.com>; Wed, 24 Jan 2007 22:35:23 -0700 (MST) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0P5ZLaF122971; Wed, 24 Jan 2007 21:35:22 -0800 (PST) Date: Wed, 24 Jan 2007 19:33:42 -1000 From: Joseph Kowalski Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: To: "Roy T. Fielding" Cc: James Carlson , Scott Rotondo , PSARC-EXT@sun.com Message-id: <45B84136.4080803@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> <17847.19287.737668.625722@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1947 Roy T. Fielding wrote: ... I agree with much or what Roy says. I also disagree with much of what he says. For the most part I don't want to get into this as a general discussion, but I think I need to point out that we need to remember that nothing is free (at least free as in beer). A number of years ago it was common knowledge around Sun that the null service call cost in excess of $100. Its probably more now. Supporting additional interfaces, which will probably generate service calls, is not free. However, that reminder is not why I'm choosing to respond... > No. The choice in that situation, were it ever to occur, is to simply > not redistribute the technology. The premise here is that there exists > a reason for distributing an overlay tools environment that behaves > according to the GNU toolset. If doing that would violate some > Solaris policy, then don't do it -- write your own tools. In this case, > I don't know of any policy that applies to the constraints that have > been mentioned so far. No such policy is documented on opensolaris.org. > > ....Roy Here I think Roy makes a very good point. The space in the OpenSolaris community workspace should only be restricted by the quality constraints and general engineering principals in the OpenSolaris mantra. Sun Solaris is free to not redistribute parts of OpenSolaris. (Its interesting to wonder who would look out of step, if tis were to happen. I'm not sure who would, but I am sure somebody would.) That said, I tend to think that export discussions aside, the root concern here is code duplication. That may or may not fit your definition of architecture, but it certainly fits mine of good engineering practice at a systems level. The trouble is that maintainers often tend to only concentrate on what benefits their little corner of the world. Part of PSARC's job, architecture or not, is to concentrate on the big picture. - jek3 From Darren.Moffat@sun.com Thu Jan 25 09:28:49 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0PHSnWk004016 for ; Thu, 25 Jan 2007 09:28:49 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0PHSlTF001729; Thu, 25 Jan 2007 09:28:49 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCF00D0RPVZC000@nwk-avmta-2.sfbay.sun.com>; Thu, 25 Jan 2007 09:28:47 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCF009WLPVYJP00@nwk-avmta-2.sfbay.sun.com>; Thu, 25 Jan 2007 09:28:47 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0PHSj6I027643; Thu, 25 Jan 2007 17:28:45 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCF00201PV37A00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 25 Jan 2007 17:28:45 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCF00JEKPVXK420@d1-emea-09.sun.com>; Thu, 25 Jan 2007 17:28:45 +0000 (GMT) Date: Thu, 25 Jan 2007 17:28:45 +0000 From: Darren J Moffat Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070123191144.GD27099@eng.sun.com> Sender: Darren.Moffat@sun.com To: Stephen Hahn Cc: Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <45B8E8CD.5070604@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061128) Status: RO Content-Length: 4846 Stephen Hahn wrote: > * Darren J Moffat [2007-01-23 03:12]: >>> I've taken a look at the code; the engineering effort required appears >>> small if we extend libmd to add the *_stream() calls used by the >>> coreutils md5sum (which is the basis of all the sha*sum utilities). >> Given that libmd is designed to be compatible with libmd on other >> systems for exactly this reason if we need to add *_stream() interfaces >> then I'm more than happy to do so. >> >> Given there are multiple issues with these specific commands I would >> highly recommend that they been dealt with in a case other than this one. > > That bring us to two choices for sha*sum: I have a third: included it! Yes I'm changing my mind but please read the full rationale below for why (basically I saw sense!). > A. These commands will be withdrawn from this case. As far as I > can see, the appropriate steps are: > > 1. File RFE against libmd5 for the new *_stream() interfaces. Nit: That would be libmd not libmd5. This seems like a perfectly reasonable RFE. One the other hand I do wonder why stdio is being used to digest files - it isn't exactly the most performance efficient way of reading files. Update: It later became clear to be that this is because GNU coreutils md5sum has a text and binary mode that the OpenSolaris digest(1) command does not. > 2. Make upstream code corrections to sha*sum. If libmd has the _stream interfaces I don't see why you would need any upstream corrections at all, just ensure that they link to libmd. Now that I've had time to think about this a bit more the real issue here is actually not about staking out filename space but about what the appropriate command to digest a file actually is for Solaris [ I'm explicitly saying Solaris here because the code underreview here isn't actually OpenSolaris code and each distribution using OpenSolaris code is free to follow or not follow what this case chooses to do, it would appear that only Solaris is committed to doing so ]. When the crypto framework was introduced that command was digest(1), there wasn't anything else in Solaris as we had never shipped md5sum or equivalent as part of Solaris before. However we later added OpenSSL and with it came the OpenSSL implementations of MD5, SHA1, etc etc and the openssl(1) command [ and thus the subcmd dgst]. $ /usr/bin/digest -v -a md5 /etc/profile $ /usr/sfw/bin/openssl dgst -md5 /etc/profile The digest(1) command uses libmd. The OpenSSL suite does not. We also have bart(1) on Solaris that does something similar, but with different file formats, to the --check argument of the GNU coreutils md5sum command. So there is already precedence for multiple commands that provide a "digest a file" functionality. 'PSARC/2005/530 digest(1) md5/md5sum compatibility' has not actually integrated yet and in reality it was filed to provide a GNU coreutils compatible md5sum. I think the correct and acceptable to me thing to do is for this case to *include* the GNU coreutils {md5,sha*}sum commands and for this case to *explicitly* supersede PSARC/2005/530. > 1. "Non-FIPS" disclaimer text will be added to required > manual pages. > Having thought about this more in the context of OpenSolaris not just Solaris this is was not actually an appropriate request. FIPS certification is (generally) applicable only to a specific set of binaries that means a specific patch release of a product such as Solaris. A FIPS certification achieved by Solaris does not automatically apply to any other OpenSolaris distribution by virtue of them using the same code. So withdraw this request it doesn't make sense. > (shred is already en route to handling similar to B. su is being > omitted based on an assessment that the cost of steps similar to A > would be uneconomic.) The really important issue with su is that unless changed the /usr/gnu variant would allow switching to users without Audit records being written since it is the responsibility of the application authenticating the user to write the records. See http://opensolaris.org/os/project/audit/ and PSARC/2007/016 http://opensolaris.org/os/community/arc/caselog/2007/016/. The GNU coreutils version also does not use PAM and would fall foul of this policy: http://opensolaris.org/os/community/arc/policies/PAM/ Aside: I find it interesting that there is a GNU coreutils su(1) but not a login(1), and also that it is su(1) not su(1M) (and lives in /usr/bin not /usr/sbin). If that is your rationale for saying uneconomic then I agree. I know that the GNU coreutils su(1) command has options the OpenSolaris su(1M) command does not, I would welcome the appropriate RFEs for the OpenSolaris version. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Thu Jan 25 09:40:19 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0PHeJmr004310 for ; Thu, 25 Jan 2007 09:40:19 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0PHeGb8018220; Thu, 25 Jan 2007 17:40:18 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCF00H0VQF45J00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Jan 2007 09:40:16 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCF00DGHQF30RE0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Jan 2007 09:40:15 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0PHeEwB000432; Thu, 25 Jan 2007 12:40:14 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0PHeERJ000429; Thu, 25 Jan 2007 12:40:14 -0500 (EST) Date: Thu, 25 Jan 2007 12:40:14 -0500 From: James Carlson Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B8E8CD.5070604@Sun.COM> To: Darren J Moffat Cc: Stephen Hahn , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <17848.60286.239584.672254@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <45B8E8CD.5070604@Sun.COM> Status: RO Content-Length: 570 Darren J Moffat writes: > I think the correct and acceptable to me thing to do is for this case to > *include* the GNU coreutils {md5,sha*}sum commands and for this case to > *explicitly* supersede PSARC/2005/530. ... and include them in /usr/bin rather than /usr/gnu/bin. That's essentially the same as I was saying before, so I agree. ;-} -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Moffat@sun.com Thu Jan 25 09:47:27 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0PHlQvb004395 for ; Thu, 25 Jan 2007 09:47:26 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0PHlM4j020222; Thu, 25 Jan 2007 17:47:25 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCF00E0JQR1PM00@nwk-avmta-2.sfbay.sun.com>; Thu, 25 Jan 2007 09:47:25 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCF0090WQR0JN30@nwk-avmta-2.sfbay.sun.com>; Thu, 25 Jan 2007 09:47:25 -0800 (PST) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0PHlNi7022562; Thu, 25 Jan 2007 17:47:23 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCF00M01QPFC900@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 25 Jan 2007 17:47:23 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCF000D8QQZ3510@d1-emea-10.sun.com>; Thu, 25 Jan 2007 17:47:23 +0000 (GMT) Date: Thu, 25 Jan 2007 17:47:23 +0000 From: Darren J Moffat Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <17848.60286.239584.672254@gargle.gargle.HOWL> Sender: Darren.Moffat@sun.com To: James Carlson Cc: Stephen Hahn , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <45B8ED2B.4020401@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <45B8E8CD.5070604@Sun.COM> <17848.60286.239584.672254@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.8 (X11/20061128) Status: RO Content-Length: 496 James Carlson wrote: > Darren J Moffat writes: >> I think the correct and acceptable to me thing to do is for this case to >> *include* the GNU coreutils {md5,sha*}sum commands and for this case to >> *explicitly* supersede PSARC/2005/530. > > ... and include them in /usr/bin rather than /usr/gnu/bin. That's > essentially the same as I was saying before, so I agree. ;-} Yes just in case it wasn't clear /usr/bin (that was implicit in the supersede PSARC/2005/530). -- Darren J Moffat From jek3@sun.com Thu Jan 25 12:15:56 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0PKFsf6009055 for ; Thu, 25 Jan 2007 12:15:55 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0PKFUD1002964; Fri, 26 Jan 2007 04:15:51 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCF00F0LXMEN900@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Jan 2007 12:15:50 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.224.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCF00L1FXMDRV90@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Jan 2007 12:15:50 -0800 (PST) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0PKFmVK315448; Thu, 25 Jan 2007 12:15:49 -0800 (PST) Date: Thu, 25 Jan 2007 10:14:07 -1000 From: Joseph Kowalski Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B8E8CD.5070604@Sun.COM> To: Darren J Moffat Cc: Stephen Hahn , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <45B90F8F.3030303@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <45B8E8CD.5070604@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 401 Darren J Moffat wrote: > Aside: I find it interesting that there is a GNU coreutils su(1) but > not a login(1), and also that it is su(1) not su(1M) (and lives in > /usr/bin not /usr/sbin). Its because su is a utility designed to let joe-user (that's me!) become the trusted user. joe-user isn't expected to have /usr/sbin on the PATH. (I'm not sure this accounts for the (1)/(1M) bit.) - jek3 From nw141292@binky.Central.Sun.COM Thu Jan 25 12:22:17 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0PKMH3A009255 for ; Thu, 25 Jan 2007 12:22:17 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0PKM9GM010119; Thu, 25 Jan 2007 12:22:15 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCF0090ZXX33X00@brm-avmta-1.central.sun.com>; Thu, 25 Jan 2007 13:22:15 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCF00F2HXX2TNC0@brm-avmta-1.central.sun.com>; Thu, 25 Jan 2007 13:22:14 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0PKLnHZ027815; Thu, 25 Jan 2007 14:21:49 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0PKLnFP027814; Thu, 25 Jan 2007 14:21:49 -0600 (CST) Date: Thu, 25 Jan 2007 14:21:49 -0600 From: Nicolas Williams Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B90F8F.3030303@sun.com> To: Joseph Kowalski Cc: Darren J Moffat , Stephen Hahn , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <20070125202148.GO12135@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <45B8E8CD.5070604@Sun.COM> <45B90F8F.3030303@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 908 On Thu, Jan 25, 2007 at 10:14:07AM -1000, Joseph Kowalski wrote: > Darren J Moffat wrote: > >Aside: I find it interesting that there is a GNU coreutils su(1) but > >not a login(1), and also that it is su(1) not su(1M) (and lives in > >/usr/bin not /usr/sbin). > Its because su is a utility designed to let joe-user (that's me!) become > the trusted user. joe-user isn't expected to > have /usr/sbin on the PATH. (I'm not sure this accounts for the (1)/(1M) > bit.) OT... So you're saying that su(1M) should really be su(1) and it should be in /bin? I tend to agree. Think of pfexec(1) as a related utility, a sort of sub-set of su(1). And if we had a way to gain authorizations by providing additional authentication, ala sudo, then pfexec(1) would be even closer to a sub-set of su, or perhaps vice-versa, su being a sub-set of pfexec. pfexec(1) is in /bin; su(1M) belongs in /bin too. Nico -- From jek3@sun.com Thu Jan 25 13:03:17 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0PL3HF2010291 for ; Thu, 25 Jan 2007 13:03:17 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0PL3EuU017509; Thu, 25 Jan 2007 13:03:15 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCF00E15ZTE9100@brm-avmta-1.central.sun.com>; Thu, 25 Jan 2007 14:03:15 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.228.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCF00FB6ZTDTNF0@brm-avmta-1.central.sun.com>; Thu, 25 Jan 2007 14:03:13 -0700 (MST) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0PL3CB8327038; Thu, 25 Jan 2007 13:03:12 -0800 (PST) Date: Thu, 25 Jan 2007 11:01:31 -1000 From: Joseph Kowalski Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070125202148.GO12135@binky.Central.Sun.COM> To: Nicolas Williams Cc: Darren J Moffat , Stephen Hahn , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <45B91AAB.50604@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <45B8E8CD.5070604@Sun.COM> <45B90F8F.3030303@sun.com> <20070125202148.GO12135@binky.Central.Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1175 Nicolas Williams wrote: > On Thu, Jan 25, 2007 at 10:14:07AM -1000, Joseph Kowalski wrote: > >> Darren J Moffat wrote: >> >>> Aside: I find it interesting that there is a GNU coreutils su(1) but >>> not a login(1), and also that it is su(1) not su(1M) (and lives in >>> /usr/bin not /usr/sbin). >>> >> Its because su is a utility designed to let joe-user (that's me!) become >> the trusted user. joe-user isn't expected to >> have /usr/sbin on the PATH. (I'm not sure this accounts for the (1)/(1M) >> bit.) >> > > OT... > > So you're saying that su(1M) should really be su(1) and it should be in > /bin? > > I tend to agree. Think of pfexec(1) as a related utility, a sort of > sub-set of su(1). And if we had a way to gain authorizations by > providing additional authentication, ala sudo, then pfexec(1) would be > even closer to a sub-set of su, or perhaps vice-versa, su being a > sub-set of pfexec. pfexec(1) is in /bin; su(1M) belongs in /bin too. > > Nico > 1: ls /usr/bin/su /usr/bin/su 2: ls /usr/sbin/su /usr/sbin/su: No such file or directory 3: uname -a SunOS hawaiin-sun 5.11 snv_52 i86pc i386 i86pc 4: Need I say more? - jek3 From nw141292@binky.Central.Sun.COM Thu Jan 25 13:05:25 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0PL5O9s010314 for ; Thu, 25 Jan 2007 13:05:24 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0PL5Hbs020332; Thu, 25 Jan 2007 21:05:22 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCF00519ZWVSL00@nwk-avmta-2.sfbay.sun.com>; Thu, 25 Jan 2007 13:05:19 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCF009C3ZWUJKF0@nwk-avmta-2.sfbay.sun.com>; Thu, 25 Jan 2007 13:05:19 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0PL4rWh028149; Thu, 25 Jan 2007 15:04:53 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0PL4rVo028148; Thu, 25 Jan 2007 15:04:53 -0600 (CST) Date: Thu, 25 Jan 2007 15:04:53 -0600 From: Nicolas Williams Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B91AAB.50604@sun.com> To: Joseph Kowalski Cc: Darren J Moffat , Stephen Hahn , Bill Sommerfeld , PSARC-EXT@sun.com Message-id: <20070125210452.GS12135@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <45B8E8CD.5070604@Sun.COM> <45B90F8F.3030303@sun.com> <20070125202148.GO12135@binky.Central.Sun.COM> <45B91AAB.50604@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 146 On Thu, Jan 25, 2007 at 11:01:31AM -1000, Joseph Kowalski wrote: > Need I say more? No, I was just confused. Thanks for the kick in the butt :) From fielding@gbiv.com Thu Jan 25 13:29:58 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0PLTue4010901 for ; Thu, 25 Jan 2007 13:29:57 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0PLTWMd023116; Fri, 26 Jan 2007 05:29:53 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCG0040511Q6U00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Jan 2007 13:29:50 -0800 (PST) Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCG00LRW11ORJB0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Jan 2007 13:29:48 -0800 (PST) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14] (may be forged)) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0PI3Wed014574; Thu, 25 Jan 2007 13:29:48 -0800 (PST) Received: from mms0aes.sun.com ([150.143.104.194] [150.143.104.194]) by relay1.sun.com with ESMTP; Thu, 25 Jan 2007 21:29:47 +0000 (Z) Received: from relay03i.sun.com ([150.143.60.74] [150.143.60.74]) by mms0aes.sun.com with ESMTP; Thu, 25 Jan 2007 21:29:47 +0000 (Z) Received: from scorpio.lunarpages.com ([209.200.229.70] [209.200.229.70]) by relay0i.sun.com with ESMTP; Thu, 25 Jan 2007 21:29:46 +0000 (Z) Received: from wsip-70-183-62-251.oc.oc.cox.net ([70.183.62.251] helo=[10.2.8.55]) by scorpio.lunarpages.com with esmtpa (Exim 4.52) id 1HACAD-0004xg-RB; Thu, 25 Jan 2007 13:29:45 -0800 Date: Thu, 25 Jan 2007 13:29:45 -0800 From: "Roy T. Fielding" Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <45B84136.4080803@sun.com> To: Joseph Kowalski Cc: PSARC-EXT@sun.com Message-id: <069BF5B0-C8E2-4C22-8B85-5B198ABB1D8E@gbiv.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - sun.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com X-Source: X-Source-Args: X-Source-Dir: References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> <17847.19287.737668.625722@gargle.gargle.HOWL> <45B84136.4080803@sun.com> Status: RO Content-Length: 3427 On Jan 24, 2007, at 9:33 PM, Joseph Kowalski wrote: > That said, I tend to think that export discussions aside, the root > concern here is code duplication. That may or may not fit your > definition of architecture, but it certainly fits mine of good > engineering practice at a systems level. If we were talking about a single integrated operating system owned and supported by one company, I would agree with you. The problem I most often face with Solaris is not duplicate code, but needing to install replacement code in order to fix bugs or missing features that, for whatever reason, won't be fixed in Solaris. This is where the value proposition of a GNU overlay makes sense. My objection was to the suggestion that an overlay of third-party code should be required to use a given Solaris implementation library prior to integration. In my opinion, that requirement contradicts the premise for creating the case, and it simply isn't reasonable to state that overlays of third-party code must reuse Solaris code. The purpose of the overlay is to allow use of a given cross-platform code base. If the suggestion was "this code is insecure" or "this code needs to exclude command XX because it does not adhere to the required audit logging mechanisms", then I could understand them as architectural concerns related to a higher-level systems requirement. Personally, I would prefer an entire prefix tree be created under /usr/gnu such that an invocation of ./configure --prefix=/usr/gnu /usr/gnu/make install would be sufficient to install any updates to those tools (and the many other co-dependent utilities produced by the FSF). I don't see the need for anything gnuish to be installed in /usr/bin, and making them separate would allow the interface "stability" to be expressed in the same way for the entire toolset. I wouldn't put all "freeware" or "linuxish" or "OSS" or other software in the same place -- just the specific set of GNU utilities that are intended to work together as a common environment, libraries, man pages, etc. > The trouble is that maintainers often tend to only concentrate on > what benefits their little corner of the world. Part of PSARC's > job, architecture or not, is to concentrate on the big picture. I honestly think you are missing the big picture. From my perspective (even with my CAB hat on), Solaris is the little corner of the world. The reason for moving towards open collaboration is so that the people making the big pictures have a chance to influence our particular style of canvas, and thus make it more useful for them before they inform their customers what platforms will be supported. As a developer, I really don't care where these tools are provided as long as it is possible to find them on the path and, once found, the tools are exactly as distributed by the tool author. I can deal with the complexity of a version check to determine how to adapt my configuration in order to use that version of the tool. What I can't deal with is a tool that claims to be one implementation but actually contains platform-specific changes due to someone else's opinion on the appropriate interface. If I wanted such an implementation, I would not be looking for the GNU toolset. In general, I only use the GNU tools when I am building on an unknown platform or when I know the operating system's native implementation is borked. ....Roy From gsf@research.att.com Thu Jan 25 13:51:14 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0PLpCee011755 for ; Thu, 25 Jan 2007 13:51:13 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0PLp3YW028672; Fri, 26 Jan 2007 05:51:07 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCG008032146400@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Jan 2007 13:51:04 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCG00LDO214RNF0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Jan 2007 13:51:04 -0800 (PST) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0PLp3mp006836; Thu, 25 Jan 2007 14:51:03 -0700 (MST) Received: from mms29es.sun.com ([150.143.232.174] [150.143.232.174]) by relay22.sun.com with ESMTP; Thu, 25 Jan 2007 21:51:03 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms29es.sun.com with ESMTP; Thu, 25 Jan 2007 21:51:02 +0000 (Z) Received: from mail-red.research.att.com ([192.20.225.110] [192.20.225.110]) by relay22.sun.com with ESMTP; Thu, 25 Jan 2007 21:51:02 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.20.192]) by mail-green.research.att.com (Postfix) with ESMTP id 32BB88574; Thu, 25 Jan 2007 16:51:02 -0500 (EST) Received: (from gsf@localhost) by penguin.research.att.com (8.13.1/8.12.10/Submit) id l0PLp2X7014222; Thu, 25 Jan 2007 16:51:02 -0500 Date: Thu, 25 Jan 2007 16:51:02 -0500 From: Glenn Fowler Subject: Re: 2007/048 Include GNU coreutils 6.4 To: fielding@gbiv.com, jek3@sun.com Cc: PSARC-EXT@sun.com Message-id: <200701252151.l0PLp2X7014222@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2006-04-17 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> <17847.19287.737668.625722@gargle.gargle.HOWL> <45B84136.4080803@sun.com> <069BF5B0-C8E2-4C22-8B85-5B198ABB1D8E@gbiv.com> Status: RO Content-Length: 815 On Thu, 25 Jan 2007 13:29:45 -0800 Roy T. Fielding wrote: > Personally, I would prefer an entire prefix tree be created > under /usr/gnu such that an invocation of > ./configure --prefix=/usr/gnu > /usr/gnu/make install [from a ksh93 hanger on] putting everything in one dir will eventually reach unresolvable version interdependency conflicts /usr/bin/foo(3.4.5.6) requires /usr/bin/bar(3.4.5.6) but /usr/bin/huh(1.2.3.4), which uses /usr/bin/bar, currently only works with /usr/bin/bar(1.2.3.4) -- so bar will hold up moving to the new foo or, /usr/bin utilities from different distributions might require specific but conflicting semantics from another /usr/bin utility going by the same name in both distributions, oh, say maybe /usr/bin/ksh -- Glenn Fowler -- AT&T Research, Florham Park NJ -- From nw141292@binky.Central.Sun.COM Thu Jan 25 14:40:04 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0PMe4e7015320 for ; Thu, 25 Jan 2007 14:40:04 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0PMe4PG004113; Thu, 25 Jan 2007 14:40:04 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCG00G094ARGM00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Jan 2007 14:40:03 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCG00F2Y4APYP20@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Jan 2007 14:40:02 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0PMdZwt028691; Thu, 25 Jan 2007 16:39:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0PMdYmP028690; Thu, 25 Jan 2007 16:39:34 -0600 (CST) Date: Thu, 25 Jan 2007 16:39:34 -0600 From: Nicolas Williams Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <200701252151.l0PLp2X7014222@penguin.research.att.com> To: Glenn Fowler Cc: fielding@gbiv.com, jek3@sun.com, PSARC-EXT@sun.com Message-id: <20070125223934.GU12135@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> <17847.19287.737668.625722@gargle.gargle.HOWL> <45B84136.4080803@sun.com> <069BF5B0-C8E2-4C22-8B85-5B198ABB1D8E@gbiv.com> <200701252151.l0PLp2X7014222@penguin.research.att.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1720 On Thu, Jan 25, 2007 at 04:51:02PM -0500, Glenn Fowler wrote: > putting everything in one dir will eventually reach unresolvable > version interdependency conflicts > > /usr/bin/foo(3.4.5.6) requires /usr/bin/bar(3.4.5.6) > but /usr/bin/huh(1.2.3.4), which uses /usr/bin/bar, currently > only works with /usr/bin/bar(1.2.3.4) -- so bar will hold up > moving to the new foo We already have this problem with things like Perl (we have two versions in Solaris now, and /usr/bin/perl can [and does!] only refer to one of those). I don't see why we couldn't follow that model in general. Now, version stability may be an issue, so that having shipped /usr/bin/foo(1.2.3.4) in Solaris 5.x we may not be able to change /usr/bin/foo to be version 3.4.5.6 until Solaris 5.x+1 or higher. > or, /usr/bin utilities from different distributions might require > specific but conflicting semantics from another /usr/bin utility > going by the same name in both distributions, oh, say maybe > /usr/bin/ksh That would mean they have conflicting names, so multiple versions (in different locations) of foo would have to be shipped. What serendipitous discovery does is make the default environment maximally useful to the average newcomer. Version dependency issues would exist with or without it, but newcomers are more likely to accidentally use the generic 'foo' instead of the specific version that they might need and then get bitten when a future, backwards- incompatible version of 'foo' replaces the generic 'foo' in /usr/bin. Ideally FOSS developers will avoid backwards-incompatible changes, but their release schedules will generally be different from Solaris' so such problems are not entirely unavoidable. Nico -- From al@logical-approach.com Thu Jan 25 18:05:01 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0Q250XH023396 for ; Thu, 25 Jan 2007 18:05:01 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0Q24xL7006924 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Fri, 26 Jan 2007 02:04:59 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCG00607DS80Z00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 25 Jan 2007 18:04:56 -0800 (PST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCG00LGQDS6TL70@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 25 Jan 2007 18:04:54 -0800 (PST) Received: from relay3.sun.com (relay3.sun.com [150.143.103.54] (may be forged)) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l0Q1UMqW028014 for ; Thu, 25 Jan 2007 18:04:54 -0800 (PST) Received: from mms0ees.sun.com ([150.143.104.244] [150.143.104.244]) by relay3.sun.com with ESMTP for PSARC-EXT@sun.com; Fri, 26 Jan 2007 02:04:53 +0000 (Z) Received: from relay4.sun.com (relay4.sun.com [150.143.103.74]) by mms0ees.sun.com with ESMTP for PSARC-EXT@sun.com; Fri, 26 Jan 2007 02:04:53 +0000 (Z) Received: from logical.logical-approach.com ([207.168.117.16] [207.168.117.16]) by relay4.sun.com with ESMTP for PSARC-EXT@sun.com; Fri, 26 Jan 2007 02:04:53 +0000 (Z) Received: from logical (logical [207.168.117.16]) by logical.logical-approach.com (8.13.5/8.13.3) with ESMTP id l0Q24NHp002853; Thu, 25 Jan 2007 20:04:24 -0600 (CST) Date: Thu, 25 Jan 2007 20:04:23 -0600 (CST) From: Al Hopper Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <200701252151.l0PLp2X7014222@penguin.research.att.com> To: Glenn Fowler Cc: PSARC-EXT@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <1169504999.28083.37.camel@thunk> <20070122224951.GF24874@eng.sun.com> <1169509935.28083.65.camel@thunk> <45B5ED9A.3090902@Sun.COM> <20070123191144.GD27099@eng.sun.com> <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> <17847.19287.737668.625722@gargle.gargle.HOWL> <45B84136.4080803@sun.com> <069BF5B0-C8E2-4C22-8B85-5B198ABB1D8E@gbiv.com> <200701252151.l0PLp2X7014222@penguin.research.att.com> Status: RO Content-Length: 1198 On Thu, 25 Jan 2007, Glenn Fowler wrote: > > On Thu, 25 Jan 2007 13:29:45 -0800 Roy T. Fielding wrote: > > Personally, I would prefer an entire prefix tree be created > > under /usr/gnu such that an invocation of > > > ./configure --prefix=/usr/gnu > > /usr/gnu/make install > > [from a ksh93 hanger on] > > putting everything in one dir will eventually reach unresolvable > version interdependency conflicts > > /usr/bin/foo(3.4.5.6) requires /usr/bin/bar(3.4.5.6) > but /usr/bin/huh(1.2.3.4), which uses /usr/bin/bar, currently > only works with /usr/bin/bar(1.2.3.4) -- so bar will hold up > moving to the new foo > > or, /usr/bin utilities from different distributions might require > specific but conflicting semantics from another /usr/bin utility > going by the same name in both distributions, oh, say maybe > /usr/bin/ksh Hi Glenn - that was really, really helpful! :) Thanks for _explaining_ it! :) Regards, Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 OpenSolaris Governing Board (OGB) Member - Feb 2006 From schilling@fokus.fraunhofer.de Fri Jan 26 04:50:21 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0QCoKlm002909 for ; Fri, 26 Jan 2007 04:50:21 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0QCnlSs021056; Fri, 26 Jan 2007 20:50:15 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCH00J0D7NLUN00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 26 Jan 2007 04:50:09 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCH00L067NLWME0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 26 Jan 2007 04:50:09 -0800 (PST) Received: from relay11.sun.com (relay11.sun.com [217.140.40.14] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0QCo8lg012215; Fri, 26 Jan 2007 05:50:08 -0700 (MST) Received: from mms13es.sun.com ([160.41.223.54] [160.41.223.54]) by relay11.sun.com with ESMTP; Fri, 26 Jan 2007 12:50:08 +0000 (Z) Received: from relay13.sun.com (relay13.sun.com [217.140.40.54]) by mms13es.sun.com with ESMTP; Fri, 26 Jan 2007 12:50:07 +0000 (Z) Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14] [193.174.154.14]) by relay13.sun.com with ESMTP; Fri, 26 Jan 2007 12:50:07 +0000 (Z) Received: from burner.fokus.fraunhofer.de (burner [10.147.65.166]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id l0QCo6907655; Fri, 26 Jan 2007 13:50:06 +0100 (MET) Received: (from jes@localhost) by burner.fokus.fraunhofer.de (8.12.9+Sun/8.12.9/Submit) id l0QCm92R012247; Fri, 26 Jan 2007 13:48:09 +0100 (CET) Date: Fri, 26 Jan 2007 13:48:09 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070125223934.GU12135@binky.Central.Sun.COM> Sender: schilling@fokus.fraunhofer.de To: Nicolas.Williams@sun.com, gsf@research.att.com Cc: PSARC-EXT@sun.com, jek3@sun.com Message-id: <45b9f889.n2IEL9EJ8km1AAxG%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.2.0.264296 References: <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> <17847.19287.737668.625722@gargle.gargle.HOWL> <45B84136.4080803@sun.com> <069BF5B0-C8E2-4C22-8B85-5B198ABB1D8E@gbiv.com> <200701252151.l0PLp2X7014222@penguin.research.att.com> <20070125223934.GU12135@binky.Central.Sun.COM> User-Agent: nail 11.22 3/20/05 Status: RO Content-Length: 726 Nicolas Williams wrote: > Ideally FOSS developers will avoid backwards-incompatible changes, but > their release schedules will generally be different from Solaris' so > such problems are not entirely unavoidable. Those changes may not always be avoided. If I am forced to introduce a backwards incompatible change, I announce this change at least 3 years before the actual change is made active. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From John.Plocher@sun.com Fri Jan 26 09:17:54 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0QHHqW3010253 for ; Fri, 26 Jan 2007 09:17:53 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0QHHffR002797; Sat, 27 Jan 2007 01:17:49 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCH00E07K1N2F00@nwk-avmta-2.sfbay.sun.com>; Fri, 26 Jan 2007 09:17:47 -0800 (PST) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCH00IHJK1LZRA0@nwk-avmta-2.sfbay.sun.com>; Fri, 26 Jan 2007 09:17:46 -0800 (PST) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0QHHjBJ027267; Fri, 26 Jan 2007 09:17:45 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCH00001JYZVE00@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Fri, 26 Jan 2007 09:17:45 -0800 (PST) Received: from [129.146.59.90] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCH00DH7K1LNI0T@d1-sfbay-10.sun.com>; Fri, 26 Jan 2007 09:17:45 -0800 (PST) Date: Fri, 26 Jan 2007 09:17:43 -0800 From: John Plocher Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070125223934.GU12135@binky.Central.Sun.COM> Sender: John.Plocher@sun.com To: Nicolas Williams Cc: Glenn Fowler , PSARC-EXT@sun.com, jek3@sun.com Message-id: <45BA37B7.9060502@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200701231920.l0NJKMqq002418@vaticaan.holland.sun.com> <20070123194529.GJ9523@binky.Central.Sun.COM> <20070123195335.GF27099@eng.sun.com> <45B6A65A.5070306@sun.com> <44CF35A1-F577-4ECE-A7C3-8ABD162AF57E@gbiv.com> <17847.19287.737668.625722@gargle.gargle.HOWL> <45B84136.4080803@sun.com> <069BF5B0-C8E2-4C22-8B85-5B198ABB1D8E@gbiv.com> <200701252151.l0PLp2X7014222@penguin.research.att.com> <20070125223934.GU12135@binky.Central.Sun.COM> User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) Status: RO Content-Length: 635 Nicolas Williams wrote: > What serendipitous discovery does is make the default environment > maximally useful to the average newcomer. Note that this problem (newcomers) is a different from that of existing users. Existing users already have startup scripts (~/.profile, ~/.login, ~/.cshrc, ...) that have explicit PATH settings. Newcomers, by definition, do not. The "put it all in /usr/bin" effort caters to the experienced user; other solutions (including simple stuff like setting /etc/default/login) would suffice for the newcomer. Let's not get carried away with "the answer is /usr/bin, what was your question?" -John From sch@rosseau.sfbay.sun.com Mon Jan 29 15:45:01 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0TNj1av023111 for ; Mon, 29 Jan 2007 15:45:01 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0TNj0k27715 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 29 Jan 2007 16:45:01 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCN00C0FLYZ1800@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 29 Jan 2007 15:44:59 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCN004JMLYZ98A0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 29 Jan 2007 15:44:59 -0800 (PST) Received: from rosseau.sfbay.sun.com (rosseau.SFBay.Sun.COM [129.146.228.252]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0TNixYS008559 for ; Mon, 29 Jan 2007 15:44:59 -0800 (PST) Received: from rosseau.sfbay.sun.com (localhost [127.0.0.1]) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0TNix7j027361 for ; Mon, 29 Jan 2007 15:44:59 -0800 (PST) Received: (from sch@localhost) by rosseau.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l0TNixGL027360 for PSARC-EXT@sun.com; Mon, 29 Jan 2007 15:44:59 -0800 (PST) Date: Mon, 29 Jan 2007 15:44:59 -0800 From: Stephen Hahn Subject: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <20070122200704.GA25978@eng.sun.com> To: PSARC-EXT@sun.com Message-id: <20070129234459.GD26985@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 7236 I've updated this case in response to specific feedback (and attempted to keep it consistent with 2007/047). - Stephen ---- | PSARC/2007/048 | Include GNU coreutils 6.7 Stephen Hahn (sch@sun.com) ident "$Hg$ SMI" 1. Summary This case adds the GNU/FSF implementations of numerous standard commands, collectively known as "coreutils", under the integration | guidelines for /usr/gnu [1]. Patch binding is sought for this case. 2. Discussion GNU coreutils--the combination of GNU fileutils, GNU shellutils, and GUN textutils--provide implementations of many common Unix utilities as well as various enhancements and additional related utilities. Providing these commands in a supported fashion on OpenSolaris is expected to conserve developer time, in that GNU extensions in common use on other platforms will be available on OpenSolaris, albeit on an alternate path. The coreutils package includes manual pages for the included commands; these will be installed in /usr/gnu/share/man. Conflicting commands and the complete commands are separated out in the interface table below. A new package, SUNWgnu-coreutils, will be introduced to deliver the binaries. | The initial version provided will be coreutils-6.7. 2.1. Omission of GNU su(1M) Although upstream open source software can be integrated with waivers on various policies surrounding internationalization or accessibility, security policies cannot be waived. Although the current implementation of GNU su is undoubtedly well-tested, it does not interact with PAM or BSM auditing and therefore would introduce | a setuid-component in violation of architectural policies [3, 4]. | It is therefore omitted from the delivered components. 2.2. Apparent provision of 'g'-prefixed GNU install(1) It turns out that GNU coreutils offers its variant of install(1M) as "ginstall"--in the standard installation of the coreutils components. Since it is non-conflicting, ginstall will also be provided in /usr/bin but is not considered a precedent-setting example of a 'g'-prefixed variant. | 2.3. Conflicts with /usr/ucb variants | | printenv(1B), users(1B), and whoami(1B) conflict with the variants | provided in the coreutils package. As each of the GNU variant | implementations are upwards compatible with the /usr/ucb variants, | this case proposes placing the non-conflicting GNU variants in | /usr/bin. | | 2.4. Hash digest commands | | The hash digest commands will be integrated in /usr/bin, and | supersede interface declarations made in PSARC/2005/530 [5]. The | project team will coordinate with other contributors to attempt to | use the libmd(3LIB) implementation in ON; the absence of such a | change will be treated as a defect. | | 2.5. Provision of shred(1) | | The coreutils package contains a command, shred(1), that relies on | filesystem implementation to operate correctly. For the most part, | the disclaimers in the shred usage message and in the shred manual | page can be enhanced to include additional disclaimers regarding | specific OpenSolaris functionality, such as ZFS. Elimination of the | command, although considered, appears to result in an unsatisfactory | deviation from the default installation, and loss of functionality | useful on devices. | | The proposed amendment would be similar to | | The following are examples of file systems on which shred is not | effective, or is not guaranteed to be effective in all file | system modes: | | * log-structured or journaled file systems, such as those | supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, | etc.) | | * file systems that write redundant data and carry on even if | + some writes fail, such as RAID-based file systems and ZFS | | + * file systems with copy-on-write semantics, such as ZFS | | + * file systems that make snapshots, such as ZFS and Network | Appliance's NFS server | | Further text of this kind can be added as appropriate. | 3. Interfaces 3.1. Non-conflicting commands. /usr/bin/ [ base64 dir dircolors | ginstall | md5sum pinky printenv ptx readlink seq | sha1sum | sha224sum | sha256sum | sha384sum | sha512sum shred shuf stat tac users vdir whoami Location Uncommitted Invocation Uncommitted | Human-readable output Not an Interface 3.2. All commands. /usr/gnu/bin/ [ base64 basename cat chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold groups head hostid hostname id install join kill link ln logname ls mkdir mkfifo mknod mv nice nl nohup od paste pathchk pinky pr printenv printf ptx pwd readlink rm rmdir seq shred shuf sleep sort split stat stty sum sync tac tail tee test touch tr true tsort tty uname unexpand uniq unlink uptime users vdir wc who whoami yes Location Uncommitted Invocation Uncommitted | Human-readable output Not an Interface /usr/share/info/coreutils.info Location Uncommitted /usr/gnu/share/man/man1/ base64.1 basename.1 cat.1 chgrp.1 chmod.1 chown.1 chroot.1 cksum.1 comm.1 cp.1 csplit.1 cut.1 date.1 dd.1 df.1 dir.1 dircolors.1 dirname.1 du.1 echo.1 env.1 expand.1 expr.1 factor.1 false.1 fmt.1 fold.1 groups.1 head.1 hostid.1 hostname.1 id.1 install.1 join.1 kill.1 link.1 ln.1 logname.1 ls.1 md5sum.1 mkdir.1 mkfifo.1 mknod.1 mv.1 nice.1 nl.1 nohup.1 od.1 paste.1 pathchk.1 pinky.1 pr.1 printenv.1 printf.1 ptx.1 pwd.1 readlink.1 rm.1 rmdir.1 seq.1 sha1sum.1 sha224sum.1 sha256sum.1 sha384sum.1 sha512sum.1 shred.1 shuf.1 sleep.1 sort.1 split.1 stat.1 stty.1 su.1 sum.1 sync.1 tac.1 tail.1 tee.1 test.1 touch.1 tr.1 true.1 tsort.1 tty.1 uname.1 unexpand.1 uniq.1 unlink.1 uptime.1 users.1 vdir.1 wc.1 who.1 whoami.1 yes.1 Location Uncommitted 4. References | [1] S. Hahn, B. Smaalders, and R. Orth, PSARC/2007/047: /usr/gnu, 2007. | | [2] S. Hahn, PSARC/2007/049: Including GNU which, 2007. | | [3] "PAM Policy", http://opensolaris.org/os/community/arc/policies/PAM/, | 2004. | | [4] "Draft Audit Policy", | http://opensolaris.org/os/community/arc/policies/audit-policy/, | 2006. | | [5] A. Muffett, PSARC/2005/530: digest(1) md5/md5sum compatibility, | 2005. -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn@sun.com http://blogs.sun.com/sch/ From gww@eng.sun.com Tue Jan 30 13:18:26 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0ULIPGM025357 for ; Tue, 30 Jan 2007 13:18:26 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0ULIPjt017856 for <@sunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Tue, 30 Jan 2007 13:18:25 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCP0050D9UPKF00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 30 Jan 2007 14:18:25 -0700 (MST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCP003A29UO3330@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 30 Jan 2007 14:18:24 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0ULINaC020709; Tue, 30 Jan 2007 13:18:23 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0ULIrMg018708; Tue, 30 Jan 2007 13:18:53 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l0ULIrQh018707; Tue, 30 Jan 2007 13:18:53 -0800 (PST) Date: Tue, 30 Jan 2007 13:18:53 -0800 (PST) From: Gary Winiger Subject: Re: 2007/048 Include GNU coreutils 6.4 To: PSARC-EXT@sun.com, sch@eng.sun.com Message-id: <200701302118.l0ULIrQh018707@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2152 > 2.1. Omission of GNU su(1M) > > Although upstream open source software can be integrated with > waivers on various policies surrounding internationalization or > accessibility, security policies cannot be waived. Although the > current implementation of GNU su is undoubtedly well-tested, it does > not interact with PAM or BSM auditing and therefore would introduce > | a setuid-component in violation of architectural policies [3, 4]. > | It is therefore omitted from the delivered components. IMO, it would be valuable to state other precedents and policies that, though not directly related to the commands of this case, they may apply to other similar cases. VIZ: PSARC/1999/555 Getting with the Freeware Program PSARC/2000/488 Solaris/Linux Commands Compatibility and PSARC/2005/185 Enabling serendipitous discovery (possibly others I don't recall) http://opensolaris.org/os/community/arc/policies/shared-sharable/ http://opensolaris.org/os/community/arc/policies/libraries/ http://opensolaris.org/os/community/arc/policies/SMF-policy/ http://opensolaris.org/os/community/arc/policies/NITS-policy/ http://opensolaris.org/os/community/arc/policies/PAM/ http://opensolaris.org/os/community/arc/policies/audit-policy/ (and possibly other policies and guidelines) > 3.1. Non-conflicting commands. > > Location Uncommitted > Invocation Uncommitted > 3.2. All commands. > Location Uncommitted > Invocation Uncommitted I'm not sure how to read this. Is this saying that the commands syntax and symantics for that syntax will not change in an incompatible with within a Minor release even if the community changes? If not, and the intent is to track the community even for incompatible changes, perhaps Volatile would be a better taxonomy. If the intent is Uncommitted, why wouldn't Committed be more appropriate? If the intent is that Sun build Committed interfaces upon these interfaces, I suspect an underlying taxonomy below Committed will require the same work to track in either case. Gary.. From gww@eng.sun.com Wed Jan 31 09:45:30 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0VHjUBh020892 for ; Wed, 31 Jan 2007 09:45:30 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0VHjPlq021980 for <@sunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Wed, 31 Jan 2007 09:45:30 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCQ00I0HUNUOU00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 31 Jan 2007 10:45:30 -0700 (MST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCQ00KKSUNT60B0@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 31 Jan 2007 10:45:29 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0VHjSRl000104; Wed, 31 Jan 2007 09:45:28 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0VHjx8b019788; Wed, 31 Jan 2007 09:46:00 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l0VHjxNY019787; Wed, 31 Jan 2007 09:45:59 -0800 (PST) Date: Wed, 31 Jan 2007 09:45:59 -0800 (PST) From: Gary Winiger Subject: Re: 2007/048 Include GNU coreutils 6.4 To: PSARC-EXT@sun.com, gww@eng.sun.com, sch@eng.sun.com Message-id: <200701311745.l0VHjxNY019787@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 626 > From gww@eng.sun.com Tue Jan 30 13:18:26 2007 > http://opensolaris.org/os/community/arc/policies/shared-sharable/ > http://opensolaris.org/os/community/arc/policies/libraries/ > http://opensolaris.org/os/community/arc/policies/SMF-policy/ > http://opensolaris.org/os/community/arc/policies/NITS-policy/ > http://opensolaris.org/os/community/arc/policies/PAM/ > http://opensolaris.org/os/community/arc/policies/audit-policy/ > (and possibly other policies and guidelines) Are there any Sun/Solaris "Big rules" that should be mentioned? E.g., i18n/l10n, accessibility (section 508)? Gary.. From roland.mainz@nrubsig.org Wed Jun 27 18:56:37 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5S1uaK5022267 for ; Wed, 27 Jun 2007 18:56:37 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5S1soAx026505 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 28 Jun 2007 02:54:52 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKB00J07PBEDN00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 27 Jun 2007 18:54:50 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKB0050TPBDJFB0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 27 Jun 2007 18:54:50 -0700 (PDT) Received: from relay24.sun.com (ip192-12-251-74.block6.us.syntegra.com [192.12.251.74]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5S1snMm020666 for ; Thu, 28 Jun 2007 01:54:49 +0000 (GMT) Received: from mms22es.sun.com ([150.143.232.34] [150.143.232.34]) by relay24.sun.com with ESMTP id BT-MMP-83520 for PSARC-EXT@sun.com; Thu, 28 Jun 2007 01:54:49 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms22es.sun.com with ESMTP id BT-MMP-949841 for PSARC-EXT@sun.com; Thu, 28 Jun 2007 01:54:49 +0000 (Z) Received: from mail-in-06.arcor-online.net ([151.189.21.46] [151.189.21.46]) by relay22.sun.com with ESMTP id BT-MMP-751028 for PSARC-EXT@sun.com; Thu, 28 Jun 2007 01:54:48 +0000 (Z) Received: from mail-in-01-z2.arcor-online.net (mail-in-05-z2.arcor-online.net [151.189.8.17]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id 3A21E31E8CA; Thu, 28 Jun 2007 03:54:48 +0200 (CEST) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id 2C3E42DA962; Thu, 28 Jun 2007 03:54:48 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-018-027.pools.arcor-ip.net [84.59.18.27]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 0E9F71BF385; Thu, 28 Jun 2007 03:54:48 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l5S1sk24008005; Thu, 28 Jun 2007 03:54:46 +0200 (CEST) Date: Thu, 28 Jun 2007 03:54:46 +0200 From: Roland Mainz Subject: GNU "readlink" conflict... / was: Re: 2007/048 Include GNU coreutils 6.4 Sender: gisburn@jupiterb48.nrubsig.org To: Stephen Hahn Cc: PSARC-EXT@sun.com Message-id: <468314E6.A9165503@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 X-Virus-Scanned: ClamAV 0.90.3/3544/Thu Jun 28 02:58:59 2007 on mail-in-04.arcor-online.net X-Virus-Status: Clean References: <20070122200704.GA25978@eng.sun.com> <20070129234459.GD26985@eng.sun.com> Status: RO Content-Length: 861 Stephen Hahn wrote: > > I've updated this case in response to specific feedback (and > attempted to keep it consistent with 2007/047). > > - Stephen > > ---- > > | PSARC/2007/048 > | Include GNU coreutils 6.7 > Stephen Hahn (sch@sun.com) > > ident "$Hg$ SMI" [snip] > 3.1. Non-conflicting commands. > > /usr/bin/ > [ > base64 > dir > dircolors > | ginstall > | md5sum > pinky > printenv > ptx > readlink Erm... I missed this part... GNU "readlink" collides with the AST "readlink" command and the ksh93 builtin version... is there still a way to move this to /usr/gnu/ ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From roland.mainz@nrubsig.org Wed Jun 27 19:59:03 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5S2x2vc023511 for ; Wed, 27 Jun 2007 19:59:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5S2v2kJ010545 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 28 Jun 2007 03:57:18 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKB00M01S7EQ400@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 27 Jun 2007 19:57:14 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKB005G4S7DJOD0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 27 Jun 2007 19:57:13 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5S2vD3q004502 for ; Thu, 28 Jun 2007 02:57:13 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay43i.sun.com with ESMTP id BT-MMP-83574 for PSARC-EXT@sun.com; Thu, 28 Jun 2007 02:57:13 +0000 (Z) Received: from relay44i.sun.com ([192.5.209.118] [192.5.209.118]) by mms49es.sun.com with ESMTP id BT-MMP-827834 for PSARC-EXT@sun.com; Thu, 28 Jun 2007 02:57:12 +0000 (Z) Received: from mail-in-04.arcor-online.net ([151.189.21.44] [151.189.21.44]) by relay4i.sun.com with ESMTP id BT-MMP-405166 for PSARC-EXT@sun.com; Thu, 28 Jun 2007 02:57:12 +0000 (Z) Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 46D0717F9B5; Thu, 28 Jun 2007 04:57:12 +0200 (CEST) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 27C872D3B28; Thu, 28 Jun 2007 04:57:12 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-018-027.pools.arcor-ip.net [84.59.18.27]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id D30BA1C331E; Thu, 28 Jun 2007 04:57:11 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l5S2v97a008030; Thu, 28 Jun 2007 04:57:10 +0200 (CEST) Date: Thu, 28 Jun 2007 04:57:09 +0200 From: Roland Mainz Subject: Re: GNU "readlink" conflict... / was: Re: 2007/048 Include GNU coreutils 6.4 Sender: gisburn@jupiterb48.nrubsig.org To: Stephen Hahn , PSARC-EXT@sun.com Message-id: <46832385.349DC0E4@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 X-Virus-Scanned: ClamAV 0.90.3/3544/Thu Jun 28 02:58:59 2007 on mail-in-05.arcor-online.net X-Virus-Status: Clean References: <20070122200704.GA25978@eng.sun.com> <20070129234459.GD26985@eng.sun.com> <468314E6.A9165503@nrubsig.org> Status: RO Content-Length: 834 Roland Mainz wrote: > Stephen Hahn wrote: [snip] > > 3.1. Non-conflicting commands. > > > > /usr/bin/ > > [ > > base64 > > dir > > dircolors > > | ginstall > > | md5sum > > pinky > > printenv > > ptx > > readlink > > Erm... I missed this part... GNU "readlink" collides with the AST > "readlink" command and the ksh93 builtin version... is there still a way > to move this to /usr/gnu/ ? ... and "stat" needs to be moved, too (ksh93s+ has "open"/"close"/"stat" and "poll" builtins... and at least the "stat" builtin works differently than the GNU stat command). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From gsf@research.att.com Wed Jun 27 20:28:50 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5S3Soir023933 for ; Wed, 27 Jun 2007 20:28:50 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5S3R1Cx015294 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 28 Jun 2007 04:27:06 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKB00F05TL5UM00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 27 Jun 2007 20:27:05 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKB00AASTL523E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 27 Jun 2007 20:27:05 -0700 (PDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5S3R40u027424 for ; Thu, 28 Jun 2007 03:27:04 +0000 (GMT) Received: from mms25es.sun.com ([150.143.232.94] [150.143.232.94]) by relay22.sun.com with ESMTP id BT-MMP-91716 for PSARC-EXT@sun.com; Thu, 28 Jun 2007 03:27:00 +0000 (Z) Received: from mms21bas.mms.us.syntegra.com (mms21bas.mms.us.syntegra.com [192.12.251.10]) by mms25es.sun.com with ESMTP id BT-MMP-1029488 for PSARC-EXT@sun.com; Thu, 28 Jun 2007 03:27:00 +0000 (Z) Received: from mail-red.research.att.com ([192.20.225.110] [192.20.225.110]) by relay25.sun.com with ESMTP id BT-MMP-780253 for PSARC-EXT@sun.com; Thu, 28 Jun 2007 03:27:00 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.20.192]) by mail-blue.research.att.com (Postfix) with ESMTP id C38FA147C90; Wed, 27 Jun 2007 23:26:55 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.1/8.12.10/Submit) id l5S3QtdU010441; Wed, 27 Jun 2007 23:26:55 -0400 Date: Wed, 27 Jun 2007 23:26:55 -0400 From: Glenn Fowler Subject: Re: GNU "readlink" conflict... / was: Re: 2007/048 Include GNU coreutils 6.4 To: roland.mainz@nrubsig.org, sch@eng.sun.com Cc: PSARC-EXT@sun.com Message-id: <200706280326.l5S3QtdU010441@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2006-04-17 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <20070129234459.GD26985@eng.sun.com> <468314E6.A9165503@nrubsig.org> Status: RO Content-Length: 293 On Thu, 28 Jun 2007 03:54:46 +0200 Roland Mainz wrote: > > readlink > Erm... I missed this part... GNU "readlink" collides with the AST > "readlink" command and the ksh93 builtin version... is there still a way > to move this to /usr/gnu/ ? ast doesn't have a readlink command ... From roland.mainz@nrubsig.org Wed Jun 27 21:12:36 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5S4CZKj024778 for ; Wed, 27 Jun 2007 21:12:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5S4Ap2r023450 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 28 Jun 2007 05:10:52 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKB00301VM3F200@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 27 Jun 2007 21:10:51 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKB005EWVM2JIF0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 27 Jun 2007 21:10:50 -0700 (PDT) Received: from relay21.sun.com (relay21.sun.com [192.12.251.14] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5S4AoVH006989 for ; Thu, 28 Jun 2007 04:10:50 +0000 (GMT) Received: from mms24es.sun.com ([150.143.232.74] [150.143.232.74]) by relay21.sun.com with ESMTP id BT-MMP-91534 for PSARC-EXT@sun.com; Thu, 28 Jun 2007 04:10:50 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms24es.sun.com with ESMTP id BT-MMP-1074619 for PSARC-EXT@sun.com; Thu, 28 Jun 2007 04:10:49 +0000 (Z) Received: from mail-in-12.arcor-online.net ([151.189.21.52] [151.189.21.52]) by relay22.sun.com with ESMTP id BT-MMP-865078 for PSARC-EXT@sun.com; Thu, 28 Jun 2007 04:10:49 +0000 (Z) Received: from mail-in-12-z2.arcor-online.net (mail-in-12-z2.arcor-online.net [151.189.8.29]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 20EE24CBE4; Thu, 28 Jun 2007 06:10:49 +0200 (CEST) Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) by mail-in-12-z2.arcor-online.net (Postfix) with ESMTP id DD76F27943C; Thu, 28 Jun 2007 06:10:48 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-018-027.pools.arcor-ip.net [84.59.18.27]) by mail-in-11.arcor-online.net (Postfix) with ESMTP id 8028611C88; Thu, 28 Jun 2007 06:10:48 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l5S4Ak3s008051; Thu, 28 Jun 2007 06:10:46 +0200 (CEST) Date: Thu, 28 Jun 2007 06:10:46 +0200 From: Roland Mainz Subject: Re: GNU "readlink" conflict... / was: Re: 2007/048 Include GNU coreutils 6.4 Sender: gisburn@jupiterb48.nrubsig.org To: Glenn Fowler Cc: sch@eng.sun.com, PSARC-EXT@sun.com Message-id: <468334C6.9810A75B@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 X-Virus-Scanned: ClamAV 0.90.3/3544/Thu Jun 28 02:58:59 2007 on mail-in-11.arcor-online.net X-Virus-Status: Clean References: <20070122200704.GA25978@eng.sun.com> <20070129234459.GD26985@eng.sun.com> <468314E6.A9165503@nrubsig.org> <200706280326.l5S3QtdU010441@penguin.research.att.com> Status: RO Content-Length: 734 Glenn Fowler wrote: > On Thu, 28 Jun 2007 03:54:46 +0200 Roland Mainz wrote: > > > readlink > > > Erm... I missed this part... GNU "readlink" collides with the AST > > "readlink" command and the ksh93 builtin version... is there still a way > > to move this to /usr/gnu/ ? > > ast doesn't have a readlink command ... No, but we added one few months ago to our side of the tree (and I wish we would've ARC'ed it immediately with PSARC 2006/550 ... than we wouldn't have the scratch-other-people's-eyes-out about this item... ;-( ) ... ;-/ ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From bart.smaalders@sun.com Thu Jun 28 10:44:58 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5SHivmO012225 for ; Thu, 28 Jun 2007 10:44:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5SHh8I4013740 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@Sun.COM>; Thu, 28 Jun 2007 18:43:12 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKC00I0ZX80E900@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu, 28 Jun 2007 10:43:12 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKC00DUQX7YTV80@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu, 28 Jun 2007 10:43:10 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5SHhA5Y024175 for ; Thu, 28 Jun 2007 10:43:10 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l5SHhAT1011905; Thu, 28 Jun 2007 10:43:10 -0700 (PDT) Date: Thu, 28 Jun 2007 10:41:05 -0700 From: Bart Smaalders Subject: Re: GNU "readlink" conflict... / was: Re: 2007/048 Include GNU coreutils 6.4 In-reply-to: <468334C6.9810A75B@nrubsig.org> To: Roland Mainz Cc: Glenn Fowler , sch@eng.sun.com, PSARC-EXT@sun.com Message-id: <4683F2B1.4070702@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <20070129234459.GD26985@eng.sun.com> <468314E6.A9165503@nrubsig.org> <200706280326.l5S3QtdU010441@penguin.research.att.com> <468334C6.9810A75B@nrubsig.org> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Status: RO Content-Length: 860 Roland Mainz wrote: > Glenn Fowler wrote: >> On Thu, 28 Jun 2007 03:54:46 +0200 Roland Mainz wrote: >>>> readlink >>> Erm... I missed this part... GNU "readlink" collides with the AST >>> "readlink" command and the ksh93 builtin version... is there still a way >>> to move this to /usr/gnu/ ? >> ast doesn't have a readlink command ... > > No, but we added one few months ago to our side of the tree (and I wish > we would've ARC'ed it immediately with PSARC 2006/550 ... than we > wouldn't have the scratch-other-people's-eyes-out about this item... ;-( > ) ... ;-/ > > ---- > > Bye, > Roland > Could someone please explain why conflicts w/ shell-builtins are important? After all, we already have conflicts with kill, pwd, limit, ... - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From roland.mainz@nrubsig.org Thu Jun 28 11:24:03 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5SIO3mi013302 for ; Thu, 28 Jun 2007 11:24:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5SIMG8W007152; Thu, 28 Jun 2007 11:22:18 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKC0040ZZ15PB00@brm-avmta-1.central.sun.com>; Thu, 28 Jun 2007 12:22:17 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKC001E5Z14ER40@brm-avmta-1.central.sun.com>; Thu, 28 Jun 2007 12:22:16 -0600 (MDT) Received: from relay21.sun.com (relay21.sun.com [192.12.251.14] (may be forged)) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5SIMGxT024325; Thu, 28 Jun 2007 18:22:16 +0000 (GMT) Received: from mms25es.sun.com ([150.143.232.94] [150.143.232.94]) by relay21.sun.com with ESMTP id BT-MMP-185965; Thu, 28 Jun 2007 18:22:16 +0000 (Z) Received: from mms21bas.mms.us.syntegra.com (mms21bas.mms.us.syntegra.com [192.12.251.10]) by mms25es.sun.com with ESMTP id BT-MMP-150395; Thu, 28 Jun 2007 18:22:15 +0000 (Z) Received: from mail-in-12.arcor-online.net ([151.189.21.52] [151.189.21.52]) by relay25.sun.com with ESMTP id BT-MMP-1566793; Thu, 28 Jun 2007 18:22:15 +0000 (Z) Received: from mail-in-01-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 8B5754CCEE; Thu, 28 Jun 2007 20:22:13 +0200 (CEST) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id 08468347126; Thu, 28 Jun 2007 20:22:13 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-003-026.pools.arcor-ip.net [84.59.3.26]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id CD4201BF399; Thu, 28 Jun 2007 20:22:12 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l5SIM9ki008189; Thu, 28 Jun 2007 20:22:10 +0200 (CEST) Date: Thu, 28 Jun 2007 20:22:09 +0200 From: Roland Mainz Subject: Re: GNU "readlink" conflict... / was: Re: 2007/048 Include GNU coreutils6.4 Sender: gisburn@jupiterb48.nrubsig.org To: Bart Smaalders , "I. Szczesniak" Cc: Glenn Fowler , sch@eng.sun.com, PSARC-EXT@Sun.COM Message-id: <4683FC51.15ED95B6@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 X-Virus-Scanned: ClamAV 0.90.3/3546/Thu Jun 28 19:09:58 2007 on mail-in-04.arcor-online.net X-Virus-Status: Clean References: <20070122200704.GA25978@eng.sun.com> <20070129234459.GD26985@eng.sun.com> <468314E6.A9165503@nrubsig.org> <200706280326.l5S3QtdU010441@penguin.research.att.com> <468334C6.9810A75B@nrubsig.org> <4683F2B1.4070702@Sun.COM> Status: RO Content-Length: 2760 Bart Smaalders wrote: > Roland Mainz wrote: > > Glenn Fowler wrote: > >> On Thu, 28 Jun 2007 03:54:46 +0200 Roland Mainz wrote: > >>>> readlink > >>> Erm... I missed this part... GNU "readlink" collides with the AST > >>> "readlink" command and the ksh93 builtin version... is there still a way > >>> to move this to /usr/gnu/ ? > >> ast doesn't have a readlink command ... > > > > No, but we added one few months ago to our side of the tree (and I wish > > we would've ARC'ed it immediately with PSARC 2006/550 ... than we > > wouldn't have the scratch-other-people's-eyes-out about this item... ;-( > > ) ... ;-/ > > Could someone please explain why conflicts w/ shell-builtins are important? If the conflicting commands are not compatible (which is at least the case for the "stat" builtin) then they cannot be enabled and bound to a path by default. Right now we already have this kind of problem with many of the ksh93 builtin commands because they implement strict POSIX behaviour while their Solaris counterparts in /usr/bin/ have pre-POSIX behaviour (e.g. PSARC 2006/550 only enabled thos builtins which are 100% compatible between Solaris and POSIX/AST. A later case may look at binding the conflicting commands to /usr/xpg6/bin/ or /usr/xpg4/bin/ but that still makes it tricky to write portable shell scripts which should still be able to run on Solaris). And that had ruined much of ksh93 benefits for Solaris (and while I am throwing stones... AFAIK most of these cases were avoidable many years ago if more attention would be paid to the standards... ;-( ) ... ;-( > After all, we already have conflicts with kill, pwd, limit, ... Yes, but some of these builtins are "special builtins" defined by the POSIX shell spec and cannot be turned off. The problem in the case above is different - we have builtins which were excluded from PSARC 2006/550 to keep the ARC case "simple" and now we're bitten by PSARC 2007/048 and will never be able to enable the matching ksh93 builtins unless we get rid of the GNU squatters in /usr/bin/. Ok... back to the tracks... ... if I recall the discussion about the /usr/gnu/bin/ ARC case correctly GNU commands need to reside in /usr/gnu/bin/ if their location in /usr/bin/ is "disputed". And I am "disputing" that place now for the "stat" and "readlink" builtins (and for "open", "close", "poll" which were explicitly developed for the ksh93-integration project on Sun's request (there aren't matching GNU tools for these right now but I am listing them for completeness...)) - claws raised and ready to fight... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From carlsonj@phorcys.east.sun.com Thu Jun 28 11:59:02 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5SIx00u015449 for ; Thu, 28 Jun 2007 11:59:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l5SIv7nZ017460; Fri, 29 Jun 2007 02:57:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKD00L070NCID00@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Jun 2007 11:57:12 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKD00D400NBTPE0@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Jun 2007 11:57:11 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5SIYf3C010989; Thu, 28 Jun 2007 14:34:41 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5SIYfFZ010986; Thu, 28 Jun 2007 14:34:41 -0400 (EDT) Date: Thu, 28 Jun 2007 14:34:41 -0400 From: James Carlson Subject: Re: GNU "readlink" conflict... / was: Re: 2007/048 Include GNU coreutils6.4 In-reply-to: <4683FC51.15ED95B6@nrubsig.org> To: Roland Mainz Cc: Bart Smaalders , "I. Szczesniak" , PSARC-EXT@sun.com Message-id: <18051.65345.416605.957793@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <20070129234459.GD26985@eng.sun.com> <468314E6.A9165503@nrubsig.org> <200706280326.l5S3QtdU010441@penguin.research.att.com> <468334C6.9810A75B@nrubsig.org> <4683F2B1.4070702@Sun.COM> <4683FC51.15ED95B6@nrubsig.org> Status: RO Content-Length: 1811 Roland Mainz writes: > Ok... back to the tracks... > ... if I recall the discussion about the /usr/gnu/bin/ ARC case > correctly GNU commands need to reside in /usr/gnu/bin/ if their location > in /usr/bin/ is "disputed". Correct. > And I am "disputing" that place now for the > "stat" and "readlink" builtins (and for "open", "close", "poll" which > were explicitly developed for the ksh93-integration project on Sun's > request (there aren't matching GNU tools for these right now but I am > listing them for completeness...)) - claws raised and ready to fight... I think the ship has sailed. The first and simplest option available at this point would be to try to convince the project team for 2007/048 (Stephen Hahn seems to be the right contact here) to alter or withdraw those components for which you see a conflict. Failing that (and you should at least try that first), the right answer is to appeal that previous decision to ARC chairs. I think we can probably drum up the required support if that's necessary. The way I read it, though, I don't see a conflict here under the original /usr/gnu case. Nothing else actually *delivers* those things to /usr/bin, so there's no conflict, and they do not need to be renamed. The "conflict" is only in ksh93's peculiar use of builtins and path bindings. I don't think the original /usr/gnu case can be construed to mean that the ARC intended to rope off all names in /usr/bin that may in the future conflict with ksh93 built-in functions. That seems like an extreme answer, and quite unhelpful to all of the other shells. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From roland.mainz@nrubsig.org Thu Jun 28 12:34:14 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5SJYErL016711 for ; Thu, 28 Jun 2007 12:34:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5SJWQU1023201; Thu, 28 Jun 2007 12:32:28 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKD00N152A40200@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Jun 2007 12:32:28 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKD00LY92A3YBB0@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Jun 2007 12:32:28 -0700 (PDT) Received: from relay24.sun.com (ip192-12-251-74.block6.us.syntegra.com [192.12.251.74]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5SJWRI8003089; Thu, 28 Jun 2007 19:32:27 +0000 (GMT) Received: from mms23es.sun.com ([150.143.232.54] [150.143.232.54]) by relay24.sun.com with ESMTP id BT-MMP-196999; Thu, 28 Jun 2007 19:32:27 +0000 (Z) Received: from mms21bas.mms.us.syntegra.com (mms21bas.mms.us.syntegra.com [192.12.251.10]) by mms23es.sun.com with ESMTP id BT-MMP-244864; Thu, 28 Jun 2007 19:32:27 +0000 (Z) Received: from mail-in-12.arcor-online.net ([151.189.21.52] [151.189.21.52]) by relay25.sun.com with ESMTP id BT-MMP-1637057; Thu, 28 Jun 2007 19:32:26 +0000 (Z) Received: from mail-in-13-z2.arcor-online.net (mail-in-13-z2.arcor-online.net [151.189.8.30]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 3EC6D4CCA8; Thu, 28 Jun 2007 21:32:15 +0200 (CEST) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mail-in-13-z2.arcor-online.net (Postfix) with ESMTP id D48B71B8E5D; Thu, 28 Jun 2007 21:32:14 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-003-026.pools.arcor-ip.net [84.59.3.26]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id 702E037A42C; Thu, 28 Jun 2007 21:32:14 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l5SJWCof008214; Thu, 28 Jun 2007 21:32:13 +0200 (CEST) Date: Thu, 28 Jun 2007 21:32:12 +0200 From: Roland Mainz Subject: Re: GNU "readlink" conflict... / was: Re: 2007/048 Include GNUcoreutils6.4 Sender: gisburn@jupiterb48.nrubsig.org To: James Carlson Cc: Bart Smaalders , "I. Szczesniak" , PSARC-EXT@sun.com Message-id: <46840CBC.8419C2CC@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 X-Virus-Scanned: ClamAV 0.90.3/3546/Thu Jun 28 19:09:58 2007 on mail-in-09.arcor-online.net X-Virus-Status: Clean References: <20070122200704.GA25978@eng.sun.com> <20070129234459.GD26985@eng.sun.com> <468314E6.A9165503@nrubsig.org> <200706280326.l5S3QtdU010441@penguin.research.att.com> <468334C6.9810A75B@nrubsig.org> <4683F2B1.4070702@Sun.COM> <4683FC51.15ED95B6@nrubsig.org> <18051.65345.416605.957793@gargle.gargle.HOWL> Status: RO Content-Length: 1867 James Carlson wrote: > Roland Mainz writes: [snip] > > And I am "disputing" that place now for the > > "stat" and "readlink" builtins (and for "open", "close", "poll" which > > were explicitly developed for the ksh93-integration project on Sun's > > request (there aren't matching GNU tools for these right now but I am > > listing them for completeness...)) - claws raised and ready to fight... > > I think the ship has sailed. ;-(( > The first and simplest option available at this point would be to try > to convince the project team for 2007/048 (Stephen Hahn seems to be > the right contact here) to alter or withdraw those components for > which you see a conflict. I am discussing the issue with him right now... > Failing that (and you should at least try that first), the right > answer is to appeal that previous decision to ARC chairs. Ouch... ;-( > I think we > can probably drum up the required support if that's necessary. > > The way I read it, though, I don't see a conflict here under the > original /usr/gnu case. Nothing else actually *delivers* those things > to /usr/bin, so there's no conflict, and they do not need to be > renamed. No, we don't deliver "open"/"close"/"poll"/"stat"/"readlink"/etc. because these and many other builtins were removed from PSARC 2006/550 because I tried to be "nice" and avoid another large chunk of work for the initial ARC case (we already had enougth controversial items like libcmd and the 64bit stuff in that case and more items like bindings for /usr/xpg6/bin/ or a fight for "open"/"close"/"poll"/"stat"/etc. looked like "too much"...). Problem is now that my attempt to be friendly now backfires badly... ;-( ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From carlsonj@phorcys.east.sun.com Thu Jun 28 13:07:25 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5SK7PH2017991 for ; Thu, 28 Jun 2007 13:07:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5SK51RL006175; Thu, 28 Jun 2007 14:05:01 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKD00B0F3TFX700@brm-avmta-1.central.sun.com>; Thu, 28 Jun 2007 14:05:39 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKD001WV3TEEP90@brm-avmta-1.central.sun.com>; Thu, 28 Jun 2007 14:05:38 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5SJh9pL011459; Thu, 28 Jun 2007 15:43:09 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5SJh9hD011456; Thu, 28 Jun 2007 15:43:09 -0400 (EDT) Date: Thu, 28 Jun 2007 15:43:09 -0400 From: James Carlson Subject: Re: GNU "readlink" conflict... / was: Re: 2007/048 Include GNUcoreutils6.4 In-reply-to: <46840CBC.8419C2CC@nrubsig.org> To: Roland Mainz Cc: Bart Smaalders , "I. Szczesniak" , PSARC-EXT@sun.com Message-id: <18052.3917.288021.239388@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070122200704.GA25978@eng.sun.com> <20070129234459.GD26985@eng.sun.com> <468314E6.A9165503@nrubsig.org> <200706280326.l5S3QtdU010441@penguin.research.att.com> <468334C6.9810A75B@nrubsig.org> <4683F2B1.4070702@Sun.COM> <4683FC51.15ED95B6@nrubsig.org> <18051.65345.416605.957793@gargle.gargle.HOWL> <46840CBC.8419C2CC@nrubsig.org> Status: RO Content-Length: 1713 Roland Mainz writes: > No, we don't deliver "open"/"close"/"poll"/"stat"/"readlink"/etc. > because these and many other builtins were removed from PSARC 2006/550 > because I tried to be "nice" and avoid another large chunk of work for > the initial ARC case (we already had enougth controversial items like > libcmd and the 64bit stuff in that case and more items like bindings for > /usr/xpg6/bin/ or a fight for "open"/"close"/"poll"/"stat"/etc. looked > like "too much"...). Problem is now that my attempt to be friendly now > backfires badly... ;-( Predicting the future is almost always troublesome. However, I don't think that this is really the wrong result. Providing /usr/bin/readlink means that other shells (such as, say, tcsh) immediately get the benefit of having that command available. It means that Solaris is one notch more friendly for refugees from Linux. In the case of ksh93, and unless I misunderstand the issue, what you're talking about is _only_ a performance tweak in ksh93 -- using built-ins in more cases where it's possible. For those other shells, it's a matter of simple usability and functionality. I don't see that as being a bad tradeoff at all. Not good if all you care about is microscopic performance of ksh93 scripts, but good for just about everyone else. (Really, if the performance of /usr/bin/readlink is a serious issue for someone, rather than the performance of some big application like Apache or Oracle, then I'd be pretty surprised.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677