Re: why are \d and \D not implemented but don't throw errors in regex?
On 12/7/2013 3:33 PM, Peter Cordes wrote: I agree your complaint seems valid, but it's the behaviour of the regex engine built into GNU libc (in this case). Bash on other platforms would use the regex engine in their system libc. (Unless I'm mistaken in my assumption that bash doesn't have its own regex engine.) Maybe Bash could follow the example of GNU grep and add the defacto perl standard as listed here: http://en.wikipedia.org/wiki/Regular_expression There, it lists the simple and extended posix, and the third standard being perl's RE: "The Perl standard is still evolving in Perl 6, but the current set of symbols and syntax has become a de facto standard. Largely because of its expressive power, many other utilities and programming languages have adopted syntax similar to Perl's — for example, Java, JavaScript, Python, Ruby, Microsoft's .NET Framework, and the W3C's XML Schema all use regular expression syntax similar to Perl's. Some languages and tools such as Boost and PHP support multiple regular expression flavors. Perl-derivative regular expression implementations are not identical and usually implement a subset of features found in Perl 5.0, released in 1994. Perl sometimes does incorporate features initially found in other languages, for example, Perl 5.10 implements syntactic extensions originally developed in PCRE and Python An option: shopt -s regex=(basic|[extended]|pcre) where 'extended' is the default would be a great extension. Likely bash could just copy the re-engine selection and use-code from grep... Certainly wouldn't violate posix to have such an option.
Re: why are \d and \D not implemented but don't throw errors in regex?
On 12/10/2013 01:28 PM, Linda Walsh wrote: > > An option: > > shopt -s regex=(basic|[extended]|pcre) > where 'extended' is the default would be a > great extension. But before bash takes on another library, it would be nicer to FIRST get libc patched to provide pcre regex by default. In other words, I think you are better off lobbying with the POSIX folks to standardize pcre as a third mode of regex worth including in libc, than you are to propose adding it to bash but letting all other regex programs (sed, grep, awk, ...) be stuck implementing pcre by themselves and possibly differently than how bash did it. Again, Chet's concern here is that the easiest way to support a particular regex syntax is to have that syntax built into the system libraries, so that ALL programs can use the same library and get the same syntax. > > Likely bash could just copy the re-engine selection and use-code from > grep... Grep uses a third-party library (libpcre) to provide it's third syntax; if that library is not present at compilation, then you can't use that flavor. So maybe bash could look into using libpcre as well. But my personal problem with libpcre is that it is bloat: bash is already bigger than dash, and requiring yet another third party library will further swing the balance away from bash for the systems that want their POSIX 'sh' to be small rather than bloated. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: why are \d and \D not implemented but don't throw errors in regex?
On 12/10/2013 12:44 PM, Eric Blake wrote: Grep uses a third-party library (libpcre) to provide it's third syntax; if that library is not present at compilation, then you can't use that flavor. So maybe bash could look into using libpcre as well. But my personal problem with libpcre is that it is bloat: bash is already bigger than dash, and requiring yet another third party library will further swing the balance away from bash for the systems that want their POSIX 'sh' to be small rather than bloated. --- Go the route vim does -- it can build in the interpreters for ruby, perl, python, -- but it can also load them dynamically -- so if you don't use any of those, you can still edit, but if you want to use one, make sure the lib is present at runtime... A bit like bash's present extensions/loadables I would think.
bash leaks sh-np-NNN files and pipes in /tmp/ when command substitution is used
Some of my scripts use command substitution, and now I see that there are lots of files like these in /tmp: prw--- 1 yuri wheel 0 Dec 10 13:32 sh-np-1386738492 -rw-r--r-- 1 yuri wheel3278909 Dec 10 14:54 sh-np-1386721176 Besides the obvious question why they aren't deleted in the end, two questions: Shouldn't bash delete the pipe files once the child process opened them? On most platforms the deleted pipe will function the same with the benefit that it will get deleted automatically. Why some of he files /tmp/sh-np-NNN are regular files, not pipes? When I look through code I see mkfifo call creates them. Shouldn't it always create fifos and not files? bash-4.2.45 FreeBSD-9.2 Yuri
