From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8536 invoked by alias); 13 Jun 2017 19:33:49 -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: 41285 Received: (qmail 25962 invoked from network); 13 Jun 2017 19:33:49 -0000 X-Qmail-Scanner-Diagnostics: from mail-wr0-f169.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.169):SA:0(-1.0/5.0):. Processed in 2.225526 secs); 13 Jun 2017 19:33:49 -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=HTML_MESSAGE, 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: brarcher@lexmark.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.169 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lexmark-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=xg4IMrDoOXT5LE96kn36zIFtiGiSFOM0bzQYOokjLAk=; b=Ep/h+BRemMXcu9r4j+LnwNbyXabsaPws+hPerOGGsamq3X2tDG2bqghF9BI5oAnLZX uIF4gCVMG148Mvc3xJEEg7Z82ff16WB8f0i9vhIhIPMUzRyZmc2Pg40R9T+QvS+DJBrd HtErTxXYFq6sJWQZdq2m8i4MKoGh1M4exNaB8JytSEGWT/FAvao3GmP9/ZlCcTqK0OtM SRuQumc2UC+uR8IaRc529KBVdgRVbdKHx3FgTw6d90oLE8OfgfsvOGVXwFQVu/TmBEY/ 5ADWpRIDJXVAW81z0TFhhhnlUmkwn0y8BWw4WGOWPkfHrVG9731VTANFMEUsgiEaJfu+ Iybg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xg4IMrDoOXT5LE96kn36zIFtiGiSFOM0bzQYOokjLAk=; b=j3wI2i7jZB0enzirzd96yj6r0Q1EhInVHeS8eVP71bKhnq/Uvk+gazZCDmSPkdQE4R 6a8owTZN0udC++5Y9Y4/55ZYqzJkIAPUbOYdLMCze5+UqJGpudbdYqYiEUSFBfkbLSgk DOYq+aDTImZJhBSEMb3NEZMBB7ZZvR+cNm+OLEWKuFI3ELeUdfyGZs0L1jq9AlDWtYqC IMJPa8HjVghqHrRqola7WUPZ75QDzVAyUd3mjsCMO8YqgVd5owZ6sujLljDj/L+JBahf tuZMcg7O8/wSBfwij6ZaUpQUrYI+TL3OIT3n46ihSD6FuWfIe1wyb/8AyzNOcJTpA2Iv 2RwQ== X-Gm-Message-State: AKS2vOzOMeOzXPwvrtMi1PhEVl9Bg+eRG8EFN4UDEi6vPAxPhhcIF5Lf yVnSZ0QfEKxb6Lr5AGwk/IY777q5HfSBEnjB6Q== X-Received: by 10.28.127.10 with SMTP id a10mr3949012wmd.36.1497382416760; Tue, 13 Jun 2017 12:33:36 -0700 (PDT) MIME-Version: 1.0 From: Branden Archer Date: Tue, 13 Jun 2017 15:32:56 -0400 Message-ID: Subject: Issue with resolving paths with zsh using \0 in variables To: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="001a1141d2ca0b92750551dc837b" --001a1141d2ca0b92750551dc837b Content-Type: text/plain; charset="UTF-8" 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. There is a workaround for this, which is to use realpath on the directory then use the result to access the file: root~# complete=$(realpath sub$(cat location)) realpath: : No such file or directory # ^ from stderr root~# echo "hi" > ${complete}/myfile However, it would be nicer if that workaround was not necessary. If you have any questions about this issue, let me know. Thanks! - Branden --001a1141d2ca0b92750551dc837b--