From owner-freebsd-standards@FreeBSD.ORG Sun Sep 1 04:00:56 2013 Return-Path: Delivered-To: freebsd-standards@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 885E1A65; Sun, 1 Sep 2013 04:00:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5E17C240C; Sun, 1 Sep 2013 04:00:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8140uru014489; Sun, 1 Sep 2013 04:00:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8140u3L014488; Sun, 1 Sep 2013 04:00:56 GMT (envelope-from linimon) Date: Sun, 1 Sep 2013 04:00:56 GMT Message-Id: <201309010400.r8140u3L014488@freefall.freebsd.org> To: dfilter@FreeBSD.ORG, linimon@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-standards@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: standards/181678: Re: standards/181240: commit references a PR X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 04:00:56 -0000 Old Synopsis: Re: standard/181240: commit references a PR New Synopsis: Re: standards/181240: commit references a PR State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sun Sep 1 03:59:14 UTC 2013 State-Changed-Why: Misfiled followup to standards/181240; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-standards Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 1 03:59:14 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=181678 From owner-freebsd-standards@FreeBSD.ORG Mon Sep 2 11:06:52 2013 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0B5B14D for ; Mon, 2 Sep 2013 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E35923B9 for ; Mon, 2 Sep 2013 11:06:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r82B6qJw016174 for ; Mon, 2 Sep 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r82B6qQC016172 for freebsd-standards@FreeBSD.org; Mon, 2 Sep 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Sep 2013 11:06:52 GMT Message-Id: <201309021106.r82B6qQC016172@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 11:06:52 -0000 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/181541 standards DRQVQzLUL8 o stand/179248 standards A return value of telldir(3) only seekable for once o stand/177742 standards conflict of dd's bs= option with use of conv=sparse o stand/176683 standards catman pages shall be stored in /var (/usr/local/var,/ o stand/176412 standards newfs writes by default, compare to bsdlabel/disklabel o stand/175711 standards When the server has more than 3 days, rising interrupt p stand/175453 standards Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 o stand/174938 standards Problem statement: iSCSI target failure o stand/173421 standards [libc] [patch] strptime() accepts formats that should o stand/173087 standards pax(1) does not support the pax interchange format o stand/172805 standards Fix catopen(3)'s EINVAL usage and document EFTYPE o stand/172276 standards POSIX: {get,set}groups gidsetsize is u_int not int o stand/172215 standards localeconv() grouping appears not to match POSIX o stand/170403 standards wrong ntohs expression type tickling clang o stand/169697 standards syslogd(8) is not BOM aware o stand/166349 standards Support the assignment-allocation character for fscanf p stand/164787 standards dirfd() function not available when _POSIX_C_SOURCE is o kern/164674 standards [patch] [libc] vfprintf/vfwprintf return error (EOF) o o stand/162434 standards getaddrinfo: addrinfo.ai_family is an address family, o stand/150093 standards C++ std::locale support is broken o stand/130067 standards Wrong numeric limits in system headers? o stand/125751 standards man 3 pthread_getschedparam section ERRORS incomplete o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) 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 a stand/86484 standards [patch] mkfifo(1) uses wrong permissions 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( o stand/56476 standards [patch] cd9660 unicode support simple hack 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/44365 standards [headers] [patch] [request] introduce ulong and unchar a stand/41576 standards ln(1): replacing old dir-symlinks a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h s stand/24590 standards timezone function not compatible witn Single Unix Spec o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 43 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Sep 2 14:55:09 2013 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C6B13D2C; Mon, 2 Sep 2013 14:55:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E6D242985; Mon, 2 Sep 2013 14:55:08 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA23213; Mon, 02 Sep 2013 17:55:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VGVX0-000N6R-SQ; Mon, 02 Sep 2013 17:55:06 +0300 Message-ID: <5224A693.3000904@FreeBSD.org> Date: Mon, 02 Sep 2013 17:54:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: FreeBSD Current , freebsd-standards@FreeBSD.org Subject: bug with special bracket expressions in regular expressions X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 14:55:09 -0000 re_format(7) says: There are two special cases‡ of bracket expressions: the bracket expres‐ sions ‘[[:<:]]’ and ‘[[:>:]]’ match the null string at the beginning and end of a word respectively. A word is defined as a sequence of word characters which is neither preceded nor followed by word characters. A word character is an alnum character (as defined by ctype(3)) or an underscore. This is an extension, compatible with but not specified by IEEE Std 1003.2 (“POSIX.2”), and should be used with caution in software intended to be portable to other systems. However I observe the following: $ echo "cd0 cd1 xx" | sed 's/cd[0-9][^ ]* *//g' xx $ echo "cd0 cd1 xx" | sed 's/[[:<:]]cd[0-9][^ ]* *//g' cd1 xx In my opinion '[[:<:]]' should not affect how the pattern is matched in this case. Any thoughts, suggestions? Thank you! -- Andriy Gapon From owner-freebsd-standards@FreeBSD.ORG Mon Sep 2 15:41:04 2013 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5CB2AF6A; Mon, 2 Sep 2013 15:41:04 +0000 (UTC) (envelope-from dweber@htw-saarland.de) Received: from triton.rz.uni-saarland.de (triton.rz.uni-saarland.de [134.96.7.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E1CFB2C39; Mon, 2 Sep 2013 15:41:03 +0000 (UTC) Received: from itz-mail.htw-saarland.de (itz-mail.htw-saarland.de [134.96.210.141]) by triton.rz.uni-saarland.de (8.14.1/8.14.0) with ESMTP id r82F9dxJ002236; Mon, 2 Sep 2013 17:09:39 +0200 Received: from magritte.htw-saarland.de (magritte.htw-saarland.de [134.96.216.98]) by itz-mail.htw-saarland.de (8.14.5/8.14.5) with ESMTP id r82F9dco026047; Mon, 2 Sep 2013 17:09:39 +0200 (CEST) Date: Mon, 2 Sep 2013 17:09:33 +0200 (CEST) From: Damian Weber To: Andriy Gapon Subject: Re: bug with special bracket expressions in regular expressions In-Reply-To: <5224A693.3000904@FreeBSD.org> Message-ID: References: <5224A693.3000904@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.3 at itz-mail X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (triton.rz.uni-saarland.de [134.96.7.25]); Mon, 02 Sep 2013 17:09:39 +0200 (CEST) X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-14; AVE: 7.9.10.68; VDF: 7.11.99.164; host: AntiVir3) Cc: FreeBSD Current , freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 15:41:04 -0000 On Mon, 2 Sep 2013, Andriy Gapon wrote: > re_format(7) says: > There are two special cases? of bracket expressions: the bracket expres? > sions ?[[:<:]]? and ?[[:>:]]? match the null string at the beginning and > end of a word respectively. A word is defined as a sequence of word > characters which is neither preceded nor followed by word characters. A > word character is an alnum character (as defined by ctype(3)) or an > underscore. This is an extension, compatible with but not specified by > IEEE Std 1003.2 (?POSIX.2?), and should be used with caution in software > intended to be portable to other systems. > > However I observe the following: > $ echo "cd0 cd1 xx" | sed 's/cd[0-9][^ ]* *//g' > xx > $ echo "cd0 cd1 xx" | sed 's/[[:<:]]cd[0-9][^ ]* *//g' > cd1 xx > > In my opinion '[[:<:]]' should not affect how the pattern is matched in this case. > > Any thoughts, suggestions? there are two simpler expressions, whose difference I don't understand either (tested on 8.4-PRERELEASE) $ echo "cd0 cd1 xx" | sed 's/cd[0-9] //g' xx $ echo "cd0 cd1 xx" | sed 's/[[:<:]]cd[0-9] //g' cd1 xx -- Damian