From bugmaster at FreeBSD.org Mon Mar 2 03:07:44 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 2 03:12:33 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200903021107.n22B70RY057458@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/130067 standards Wrong numeric limits in system headers? o stand/129554 standards lp(1) [patch] Implement -m and -t options o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/119804 standards [locale] [patch] Invalid (long)date format in pl_PL.IS o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/72006 standards floating point formating in non-C locales o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o stand/25777 standards [kernel] [patch] atime not updated on exec o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 52 problems total. From das at FreeBSD.org Tue Mar 3 22:25:08 2009 From: das at FreeBSD.org (das@FreeBSD.org) Date: Tue Mar 3 22:25:14 2009 Subject: standards/72006: floating point formating in non-C locales Message-ID: <200903040625.n246P7o6054955@freefall.freebsd.org> Synopsis: floating point formating in non-C locales State-Changed-From-To: open->closed State-Changed-By: das State-Changed-When: Wed Mar 4 06:22:04 UTC 2009 State-Changed-Why: As far as I know, *printf() and *scanf() handle locale-specific decimal and thousands' separators correctly. They're not supposed to consider a '.' to be a decimal separator in locales where the decimal separator is another character. http://www.freebsd.org/cgi/query-pr.cgi?pr=72006 From bugmaster at FreeBSD.org Mon Mar 9 10:15:19 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 9 10:17:32 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200903091715.n29HFDhf045403@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/130067 standards Wrong numeric limits in system headers? o stand/129554 standards lp(1) [patch] Implement -m and -t options o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/119804 standards [locale] [patch] Invalid (long)date format in pl_PL.IS o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o stand/25777 standards [kernel] [patch] atime not updated on exec o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 51 problems total. From bugmaster at FreeBSD.org Mon Mar 16 04:07:04 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 16 04:09:26 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200903161107.n2GB738a043405@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/130067 standards Wrong numeric limits in system headers? o stand/129554 standards lp(1) [patch] Implement -m and -t options o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/119804 standards [locale] [patch] Invalid (long)date format in pl_PL.IS o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o stand/25777 standards [kernel] [patch] atime not updated on exec o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 51 problems total. From olli at lurza.secnetix.de Wed Mar 18 05:13:53 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Mar 18 05:14:00 2009 Subject: Suspecting bug in /bin/sh's IFS Message-ID: <200903181213.n2ICDPpT042350@lurza.secnetix.de> Hello, According to the sh(1) manpage and the SUSv3 wording, the order of characters in the IFS variable should not matter for field splitting. However, I get strange results with our /bin/sh ... I'm trying to parse config files that look like this: ip = 10.1.2.3 host = some.name desc = some description here That is, the format of lines is this: * "=" * Of course that should be simple: Just add "=" to $IFS and read the lines in a loop, like the following (the echo command is for debugging; the real shell code uses the setvar command instead): IFS="=$IFS" while read key val; do echo "'$key' -- '$val'" done < config However, the "=" characters and some spaces are included in $val, which is wrong behaviour, I think. I get this output: 'ip' -- ' = 10.1.2.3' 'host' -- '= some.name' 'desc' -- '= some description here' If I change the IFS line like this (diff -u format): - IFS="=$IFS" + IFS="$IFS=" then I get the correct and expected output: 'ip' -- '10.1.2.3' 'host' -- 'some.name' 'desc' -- 'some description here' Note that the characters in IFS are exactly the same, only the order is different. On Solaris, the same shell script produces correct output in both cases, independent from the order of characters in IFS. I've also tested zsh and bash: They also produce correct output in both cases. So this really seems to be a bug in FreeBSD's /bin/sh. I'm about to file a PR, but I suppose it's better to ask the standards mailinglist first, so here I am. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd From olli at lurza.secnetix.de Thu Mar 19 07:13:04 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Mar 19 07:13:11 2009 Subject: Suspecting bug in /bin/sh's IFS In-Reply-To: <200903181213.n2ICDPpT042350@lurza.secnetix.de> Message-ID: <200903191412.n2JECdbl011120@lurza.secnetix.de> Further debugging reveals that this is not a generic problem with field splitting, but it affects the read command only. I tried to use "set" instead of "read": ORIG_IFS="$IFS" while read line; do IFS="$IFS=" set -- $line IFS="$ORIG_IFS" key="$1" shift val="$*" echo "'$key' -- '$val'" done < config Now i get correct output for both " \t\n=" and "= \t\n" as the IFS value. So the bug is in the "read" builtin. The following patch fixes the problem: --- bin/sh/miscbltin.c.orig 2006-02-04 15:37:50.000000000 +0100 +++ bin/sh/miscbltin.c 2009-03-19 15:01:43.000000000 +0100 @@ -188,7 +188,7 @@ } if (c == '\n') break; - if (startword && *ifs == ' ' && strchr(ifs, c)) { + if (startword && strchr(ifs, c)) { continue; } startword = 0; The bug seems to exist for at least 15 years; the bogus comparison was already present in the initial import in the FreeBSD CVS repository in 1994. Any opinions on this? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Whatever happened to the days when hacking started at the cerebral cortex, and not at the keyboard?" -- Sid on userfriendly.org by Illiad, 2007-06-20 From jilles at stack.nl Sat Mar 21 15:04:01 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sat Mar 21 15:04:09 2009 Subject: Suspecting bug in /bin/sh's IFS In-Reply-To: <200903191412.n2JECdbl011120@lurza.secnetix.de> References: <200903181213.n2ICDPpT042350@lurza.secnetix.de> <200903191412.n2JECdbl011120@lurza.secnetix.de> Message-ID: <20090321214634.GA36395@stack.nl> On Thu, Mar 19, 2009 at 03:12:39PM +0100, Oliver Fromme wrote: > Further debugging reveals that this is not a generic > problem with field splitting, but it affects the read > command only. > I tried to use "set" instead of "read": > ORIG_IFS="$IFS" > while read line; do > IFS="$IFS=" > set -- $line > IFS="$ORIG_IFS" > key="$1" > shift > val="$*" > echo "'$key' -- '$val'" > done < config > Now i get correct output for both " \t\n=" and "= \t\n" > as the IFS value. So the bug is in the "read" builtin. > The following patch fixes the problem: > --- bin/sh/miscbltin.c.orig 2006-02-04 15:37:50.000000000 +0100 > +++ bin/sh/miscbltin.c 2009-03-19 15:01:43.000000000 +0100 > @@ -188,7 +188,7 @@ > } > if (c == '\n') > break; > - if (startword && *ifs == ' ' && strchr(ifs, c)) { > + if (startword && strchr(ifs, c)) { > continue; > } > startword = 0; > The bug seems to exist for at least 15 years; the bogus > comparison was already present in the initial import in > the FreeBSD CVS repository in 1994. > Any opinions on this? The code is wrong, but your patched code is also wrong. The read builtin should use the same logic as normal field splitting, with additional rules if there are more fields in the input than variables. I have noticed that NetBSD has already fixed this. I have ported these fixes over: http://www.stack.nl/~jilles/unix/sh-read-split.patch The patch is against RELENG_7, I hope it applies to -CURRENT as well. The NetBSD commit message also refers to http://www.research.att.com/~gsf/public/ifs.sh Just like their /bin/sh, our /bin/sh with the patch now passes the 'read' tests from there (there are still many other failures though). By the way, to avoid all processing by read, one must IFS= read -r VAR. Without the IFS specification, leading and trailing whitespace will still be stripped. -- Jilles Tjoelker From wxs at FreeBSD.org Sun Mar 22 08:04:35 2009 From: wxs at FreeBSD.org (Wesley Shields) Date: Sun Mar 22 08:04:42 2009 Subject: FW: shell choice freebsd git port Message-ID: <20090322144753.GA48259@atarininja.org> As the maintainer of devel/git I'd like this port to do the right thing, but I'm not sure if this is a legitimate bug in our /bin/sh or not. Anyone care to comment on this? -- WXS ----- Forwarded message from Jeff King ----- Date: Sun, 22 Mar 2009 05:37:10 -0400 From: Jeff King To: wxs@freebsd.org Subject: shell choice freebsd git port Hi, I'm one of the upstream developers of git, and it looks like you are the git ports maintainer for FreeBSD. I wanted to discuss an issue which you may run into while packaging git 1.6.2.1. It seems that FreeBSD's /bin/sh treats blank lines in an eval as a successful command. E.g., (the output is from FreeBSD 6.1, but I built the current HEAD from anoncvs and it seems to have the same problem): $ /bin/sh $ eval 'false ' $ echo $? 0 (whereas bash and dash would print '1'). This is problematic for our test suite, which consists of a lot of eval'ing. Failing tests may be missed if their status is ignored, one test in 1.6.2.1 which expects a non-zero exit status actually does report failure when it actually succeeded. On top of that, some of the scripts (like bisect and filter-branch) care about the exit status of evals at run-time to determine whether an error occurred. There is some discussion on the git list here: http://thread.gmane.org/gmane.comp.version-control.git/112519/focus=112621 I don't know if you want to do anything to the port to work around this. The obvious solution is requiring bash, and setting SHELL_PATH appropriately in the Makefile. You may also want to see if anyone is interested in treating this like a bug in /bin/sh and fixing it (I consider it a bug, but others may consider it historical behavior, I suppose). -Peff ----- End forwarded message ----- From mikolas.janota at gmail.com Sun Mar 22 08:17:45 2009 From: mikolas.janota at gmail.com (=?UTF-8?B?TWlrb2zDocWhIEphbm90YQ==?=) Date: Sun Mar 22 08:17:52 2009 Subject: POSIX conformance of ls -l -1 Message-ID: <682003a60903220754g6c653582lb346f8e8d6bf63cf@mail.gmail.com> For the command ls, the POSIX standard, says that "When -l (ell) is specified, -1 (one) shall be assumed." (http://www.opengroup.org/onlinepubs/000095399/utilities/ls.html) In the FreeBSD implementation, however, -1 and -l override one another. I can't see how this could be POSIX compliant. I'm on Mac OS X which I believe is using FreeBSD port and the man page claims POSIX compliance. Where can I find more information about this? -- Mikol?? Janota M. Sc. School of Computer Science and Informatics, University College Dublin, Belfield, Dublin 4, Ireland From das at FreeBSD.ORG Sun Mar 22 09:57:13 2009 From: das at FreeBSD.ORG (David Schultz) Date: Sun Mar 22 09:57:34 2009 Subject: POSIX conformance of ls -l -1 In-Reply-To: <682003a60903220754g6c653582lb346f8e8d6bf63cf@mail.gmail.com> References: <682003a60903220754g6c653582lb346f8e8d6bf63cf@mail.gmail.com> Message-ID: <20090322163200.GA74989@zim.MIT.EDU> On Sun, Mar 22, 2009, Mikol?? Janota wrote: > For the command ls, the POSIX standard, says that "When -l (ell) is > specified, -1 (one) shall be assumed." > (http://www.opengroup.org/onlinepubs/000095399/utilities/ls.html) > > In the FreeBSD implementation, however, -1 and -l override one > another. I can't see how this could be POSIX compliant. > > I'm on Mac OS X which I believe is using FreeBSD port and the man page > claims POSIX compliance. Where can I find more information about this? Perhaps it's a bug. Comments in the source seem to indicate that it was done this way on purpose, though. If you have `ls' aliased to `ls -laG', for example, you can still use `ls -1' on the command line to force the single-line output (as if the options were `ls -aG'.) I'm not sure what we ought to do about it. From mikolas.janota at gmail.com Sun Mar 22 15:01:47 2009 From: mikolas.janota at gmail.com (=?UTF-8?B?TWlrb2zDocWhIEphbm90YQ==?=) Date: Sun Mar 22 15:01:53 2009 Subject: POSIX conformance of ls -l -1 In-Reply-To: <20090322163200.GA74989@zim.MIT.EDU> References: <682003a60903220754g6c653582lb346f8e8d6bf63cf@mail.gmail.com> <20090322163200.GA74989@zim.MIT.EDU> Message-ID: <682003a60903221501i31d93f58r845c9e3f18ab9695@mail.gmail.com> On Sun, Mar 22, 2009 at 4:32 PM, David Schultz wrote: > On Sun, Mar 22, 2009, Mikol?? Janota wrote: >> For the command ls, the POSIX standard, says that "When -l (ell) is >> specified, -1 (one) shall be assumed." >> (http://www.opengroup.org/onlinepubs/000095399/utilities/ls.html) >> >> In the FreeBSD implementation, however, -1 and -l override one >> another. I can't see how this could be POSIX compliant. >> >> I'm on Mac OS X which I believe is using FreeBSD port and the man page >> claims POSIX compliance. Where can I find more information about this? > > Perhaps it's a bug. Comments in the source seem to indicate that > it was done this way on purpose, though. If you have `ls' aliased > to `ls -laG', for example, you can still use `ls -1' on the command > line to force the single-line output (as if the options were `ls -aG'.) > I'm not sure what we ought to do about it. > I think the problem is that -1 is interpreted sometimes as "single-column" and sometimes as "one-per-line". The gnu implementation of ls follows the POSIX standard and ls -l -1 is the same as ls -l, but if you write --format=long --format=single-column, long is overriden. Even though --format=single-column and -1 should be the same. -- Mikol?? From jilles at stack.nl Sun Mar 22 15:04:00 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sun Mar 22 15:04:07 2009 Subject: FW: shell choice freebsd git port In-Reply-To: <20090322144753.GA48259@atarininja.org> References: <20090322144753.GA48259@atarininja.org> Message-ID: <20090322214741.GA50879@stack.nl> On Sun, Mar 22, 2009 at 10:47:53AM -0400, Wesley Shields wrote: > As the maintainer of devel/git I'd like this port to do the right thing, > but I'm not sure if this is a legitimate bug in our /bin/sh or not. > Anyone care to comment on this? > ----- Forwarded message from Jeff King ----- > Date: Sun, 22 Mar 2009 05:37:10 -0400 > From: Jeff King > To: wxs@freebsd.org > Subject: shell choice freebsd git port > Hi, > I'm one of the upstream developers of git, and it looks like you are the > git ports maintainer for FreeBSD. I wanted to discuss an issue which you > may run into while packaging git 1.6.2.1. > It seems that FreeBSD's /bin/sh treats blank lines in an eval as a > successful command. E.g., (the output is from FreeBSD 6.1, but I built > the current HEAD from anoncvs and it seems to have the same problem): > $ /bin/sh > $ eval 'false > > ' > $ echo $? > 0 > (whereas bash and dash would print '1'). > This is problematic for our test suite, which consists of a lot of > eval'ing. Failing tests may be missed if their status is ignored, one > test in 1.6.2.1 which expects a non-zero exit status actually does > report failure when it actually succeeded. On top of that, some of the > scripts (like bisect and filter-branch) care about the exit status of > evals at run-time to determine whether an error occurred. > There is some discussion on the git list here: > http://thread.gmane.org/gmane.comp.version-control.git/112519/focus=112621 > I don't know if you want to do anything to the port to work around this. > The obvious solution is requiring bash, and setting SHELL_PATH > appropriately in the Makefile. You may also want to see if anyone is > interested in treating this like a bug in /bin/sh and fixing it (I > consider it a bug, but others may consider it historical behavior, I > suppose). As discussed on IRC, I think this is a bug in /bin/sh. Just from reading the code, NetBSD does not seem to have fixed this. The following patch seems to fix the problem: http://www.stack.nl/~jilles/unix/sh-eval-emptyline.patch Apart from 'eval', also 'trap', 'fc' and strings passed with '-c' are affected. Empty lines inside {}, if or similar constructs are treated differently and work fine even without the patch. -- Jilles Tjoelker From stefan at fafoe.narf.at Sun Mar 22 15:32:03 2009 From: stefan at fafoe.narf.at (Stefan Farfeleder) Date: Sun Mar 22 15:32:09 2009 Subject: Suspecting bug in /bin/sh's IFS In-Reply-To: <20090321214634.GA36395@stack.nl> References: <200903181213.n2ICDPpT042350@lurza.secnetix.de> <200903191412.n2JECdbl011120@lurza.secnetix.de> <20090321214634.GA36395@stack.nl> Message-ID: <20090322221540.GA1269@lizard.fafoe.narf.at> On Sat, Mar 21, 2009 at 10:46:34PM +0100, Jilles Tjoelker wrote: > > The code is wrong, but your patched code is also wrong. The read builtin > should use the same logic as normal field splitting, with additional > rules if there are more fields in the input than variables. > > I have noticed that NetBSD has already fixed this. I have ported these > fixes over: http://www.stack.nl/~jilles/unix/sh-read-split.patch > The patch is against RELENG_7, I hope it applies to -CURRENT as well. > > The NetBSD commit message also refers to > http://www.research.att.com/~gsf/public/ifs.sh > Just like their /bin/sh, our /bin/sh with the patch now passes the > 'read' tests from there (there are still many other failures though). > > By the way, to avoid all processing by read, one must IFS= read -r VAR. > Without the IFS specification, leading and trailing whitespace will > still be stripped. Thank you, I have committed this patch. From bugmaster at FreeBSD.org Mon Mar 23 04:07:05 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 23 04:09:25 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200903231107.n2NB74Fu004159@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/130067 standards Wrong numeric limits in system headers? o stand/129554 standards lp(1) [patch] Implement -m and -t options o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/119804 standards [locale] [patch] Invalid (long)date format in pl_PL.IS o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o stand/25777 standards [kernel] [patch] atime not updated on exec o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 51 problems total. From olli at lurza.secnetix.de Tue Mar 24 03:55:58 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Mar 24 03:56:05 2009 Subject: Suspecting bug in /bin/sh's IFS In-Reply-To: <20090322221540.GA1269@lizard.fafoe.narf.at> Message-ID: <200903241055.n2OAtQKr035646@lurza.secnetix.de> Stefan Farfeleder wrote: > Jilles Tjoelker wrote: > > The code is wrong, but your patched code is also wrong. The read builtin > > should use the same logic as normal field splitting, with additional > > rules if there are more fields in the input than variables. > > > > I have noticed that NetBSD has already fixed this. I have ported these > > fixes over: http://www.stack.nl/~jilles/unix/sh-read-split.patch > > The patch is against RELENG_7, I hope it applies to -CURRENT as well. > > > > The NetBSD commit message also refers to > > http://www.research.att.com/~gsf/public/ifs.sh > > Just like their /bin/sh, our /bin/sh with the patch now passes the > > 'read' tests from there (there are still many other failures though). > > > > By the way, to avoid all processing by read, one must IFS= read -r VAR. > > Without the IFS specification, leading and trailing whitespace will > > still be stripped. > > Thank you, I have committed this patch. Cool, thanks! -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "A misleading benchmark test can accomplish in minutes what years of good engineering can never do." -- Dilbert (2009-03-02) From bugmaster at FreeBSD.org Mon Mar 30 04:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 30 04:09:22 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200903301107.n2UB70Hg054915@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/130067 standards Wrong numeric limits in system headers? o stand/129554 standards lp(1) [patch] Implement -m and -t options o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/119804 standards [locale] [patch] Invalid (long)date format in pl_PL.IS o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o stand/25777 standards [kernel] [patch] atime not updated on exec o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 51 problems total.