From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21881 invoked by alias); 16 Jun 2017 06:41:38 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 41309 Received: (qmail 8730 invoked from network); 16 Jun 2017 06:41:38 -0000 X-Qmail-Scanner-Diagnostics: from mail-wr0-f179.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.128.179):SA:0(-1.0/5.0):. Processed in 0.795571 secs); 16 Jun 2017 06:41:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: stephane.chazelas@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.128.179 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=S1OKYR5H8QYl9gfBcz2153ZUdI129VLPqOdyUqM/+Nc=; b=r9p9btkLjCwmpvQ1TdtufYfM+fuCnyqcASOAGtN90BJcxLEFFsHxMeCywZP098prLs tnMdPska82rUB4v9gJ3VotIHYDGUy5e5EODfF9DX4MephWKTdPaDA0GZVNZvG8Ixtqbc TcvyY9FQ4Zw5IvigSubOvUhKbosQKcphSyMXy1MQlxTlR3qz7M4YZCWV7Blg/mfeCTOL YWWfPsK3t9dsskpopxqnFJQNWYSwbX+waq/kYLKtbeueWc7nXMb9KqQ747XPGydmLmbj Fu8GXFaN7mcQ39DYE+EdJO7v6P7UBbDkdN6geKVthl/5ej+PCdsaeJFBxGKm17qVIqgn 5Qow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=S1OKYR5H8QYl9gfBcz2153ZUdI129VLPqOdyUqM/+Nc=; b=gOpaV3rMHBvqfBH/dZC9X+8Z4ciPqgAy0M1hGgd60KzxtEzGQHH3Pgfi0MR69TqMbA WeIb+t++kyrugX8H3lKAIJ4Kt8W+RbQLMir8ayoJ4M+H0sCOlh1qZfxnjx4XM5UmOnJu 33lsQjjr+cTXrRXql6rPYS9nY0Pacc5N1pd0Wy33Ua1vO3eR5hnVDcEUQ50KBAoUwVgq G+RDdey4Cd2LrpvZei7hLgE0rhJH6UbzjNWkXwrMiC7uWuxrnkCo7Dt4q+8Mqe26E7dq lAbRzCHLAZtUBPcGD+zSB7FIS41u7D93q+T2ulYggDvJI8IedXrpWakqAw/NR7y18avH dBUg== X-Gm-Message-State: AKS2vOwotRQFJQlTV3Q9mVqJZzZF0jCFaskSOowC2bSDUqpAMOXwWZ29 bEEMl+KWEXguSB6v X-Received: by 10.223.170.193 with SMTP id i1mr5671886wrc.143.1497595291981; Thu, 15 Jun 2017 23:41:31 -0700 (PDT) Date: Fri, 16 Jun 2017 07:41:29 +0100 From: Stephane Chazelas To: Phil Pennock Cc: zsh-workers@zsh.org Subject: Re: [PATCH] PCRE/NUL: pass NUL in for text, handle NUL out Message-ID: <20170616064129.GA19469@chaz.gmail.com> Mail-Followup-To: Phil Pennock , zsh-workers@zsh.org References: <20170615204050.GA27003@breadbox.private.spodhuis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170615204050.GA27003@breadbox.private.spodhuis.org> User-Agent: Mutt/1.5.24 (2015-08-30) 2017-06-15 16:40:50 -0400, Phil Pennock: > The regexp itself is always NUL-terminated, so detect embedded NULs and > zwarn on their presence. [...] Thanks Phil. Maybe an improvement could be to replace those NULs with a litteral \0. Though that would not be valid if the NUL is preceded by a backslash or within \Q...\E. So it's probably just as well to use the warning to let the user do the escaping himself. Having a way to use \Q...\E reliably would be nice by the way As in a variant of: [[ $x =~ "...\Q$y\E" ]] That still works if $y contains \E. (I can't think of a reasonable way though). bash32+/ksh93 support: [[ $x =~ ..."$y"...]] as in quoting $y prevents interpretation of RE operators in them. It's quite buggy in ksh93, and in bash, that means the syntax is limited to POSIX ERE even on systems where EREs have many extensions like \<, back-references... (except if you store the regex in a variable which you then leave unquoted: ws='\<' we='\>'; [[ $var = $ws"$word"$we ]], not [[ $var = \<"$word"\> ]]) so I'm not sure we want to go there. Solution for now in zsh is to escape like: [[ $x =~ "\b\Q${word//\\E/\\E\\\\E\\Q}\E" ]] (possibly still doesn't work in locales that have characters whose encoding ends in 0x5c bytes (same as \), but nobody should use those really in this day and age). -- Stephane