From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25284 invoked by alias); 14 Jun 2017 02:25:20 -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: 41286 Received: (qmail 16420 invoked from network); 14 Jun 2017 02:25:20 -0000 X-Qmail-Scanner-Diagnostics: from mout.gmx.net 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(212.227.15.19):SA:0(-1.0/5.0):. Processed in 2.110784 secs); 14 Jun 2017 02:25:20 -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 autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: llua@gmx.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at gmx.com designates 212.227.15.19 as permitted sender) Subject: Re: Issue with resolving paths with zsh using \0 in variables To: zsh-workers@zsh.org References: From: Eric Cook Message-ID: Date: Tue, 13 Jun 2017 20:38:23 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0ZkvgKjNEcUVQTudlZ7H7cqkjTtx9+1bCxca8139Ty6XFlrwghD 0x+P88lF3hivVRU40j6eWt9cxozJ1Ds16PLqM/9pKAc5WLNmIPMX4DhHE4U27xwA/KD1hbq ZunT8WFeLwT/QI0+hU7wBm9w/HFQzv9exSfIKqrWEZECAxxSpLAEaZcHdLz+QHq3LiVF5EA Dgf12JPzcDe21Svr2smrA== X-UI-Out-Filterresults: notjunk:1;V01:K0:MRBq1ZPf0pE=:79OTwDyJ6MT2chj0tacIie ix2+0puF5Hf3aR4RfuxEFgpBPjjzyrqSzXJ2ke0xWmJtETd4l192i95Ei93WbYDoRFASvGeAz Sl6pO75w6phCveuzbU8yrTNjlF99HUyl4ZttgzxuwQw6nqwLHhJPSjJoej+9yBag6ATZG8Jpy jt0RXpyGwALbdzqLkpEuUh2mBGtTDzQ0CZVNuOKnawDGIs33OfnPev/UdaL1C24PIPj0KHenc zbbYWQKR5qb+d1IFPo8AOzedoTPfQ4yNgRiOsVOAYriNfOXihI5OdqSXEb46ZPdg8alcAdQgM uM5n+SYyBYxfKIIoTS03NIv9DQxIYMoYVHwyENh/jlUumvnOxGBH9pS05Fd2jymQADqs0dotU e8rx3j2I+C4PcmRa+3Mzq9UhoUt7HtejoKSxgFzCm5WwIv2u6JlyvOcwM1F+G+H/OB9HjHwnb HHslPd+BkkSYsJYLUMcx7+md6rSx+8ZfP54M4trJkGsC7HXj4ij8AwXRvy/OkzgoxN0QqAxwi COLUYETrvjPpdqRXPIhvSEBFFz1BIt18KiHOBRQsPnxo3m9SC9cj3k39s7wK5b0lKgWXtdxt6 ZnFOvjdvcK0V8RO/43tlo2TgCICv4wKIrTYU22wrpRnMcxQEyvI1OMBS+DGPn3gwjskann1HF 1PaYg8DAPVXFqGEhafOv1zqkJVvVP17/1ZGi5/lvL6jnhlLDYbdP1kaadz19ormJOIrUf3VQ3 49YzdgJ8gJDdRz+B5rcaqSk3KCDnnHX+QUoIhujir99JrTVSkzZkEb/pR1xxMqXUAtUcYeFGM KL37FDZ On 06/13/2017 03:32 PM, Branden Archer wrote: > This is an issue found when attempting to use paths in zsh where parts of > the path are taken from data on the /sys filesystem. Namely, when cat'ing a > file from the /sys filesystem it may return some data with a \0 at the end. > If that variable is used to form a path the \0 interferes with the path > resolution. Here is an example of this: > > > root~# echo $ZSH_VERSION > 5.3.1 > root~# mkdir subdir > root~# > root~# printf "dir\0" > location > root~# touch subdir/myfile > root~# echo "hi" > sub$(cat location)/myfile > zsh: is a directory: subdir > root~# echo "hi" > subdir/myfile > > > It was found on bash that this did work, so it is believed that this is a > valid use case. Namely, on bash the \0 at the end of the data returned > from $(cat > location) is ignored. Silently mangling input isn't a valid usecase, even recently in bash there is an warning that is displayed when it happens. http://lists.gnu.org/archive/html/bug-bash/2017-04/msg00016.html