* Issue with resolving paths with zsh using \0 in variables
@ 2017-06-13 19:32 Branden Archer
2017-06-14 0:38 ` Eric Cook
2017-06-14 23:02 ` Bart Schaefer
0 siblings, 2 replies; 6+ messages in thread
From: Branden Archer @ 2017-06-13 19:32 UTC (permalink / raw)
To: zsh-workers
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Issue with resolving paths with zsh using \0 in variables
2017-06-13 19:32 Issue with resolving paths with zsh using \0 in variables Branden Archer
@ 2017-06-14 0:38 ` Eric Cook
2017-06-14 23:02 ` Bart Schaefer
1 sibling, 0 replies; 6+ messages in thread
From: Eric Cook @ 2017-06-14 0:38 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Issue with resolving paths with zsh using \0 in variables
2017-06-13 19:32 Issue with resolving paths with zsh using \0 in variables Branden Archer
2017-06-14 0:38 ` Eric Cook
@ 2017-06-14 23:02 ` Bart Schaefer
2017-06-15 3:40 ` Eric Cook
1 sibling, 1 reply; 6+ messages in thread
From: Bart Schaefer @ 2017-06-14 23:02 UTC (permalink / raw)
To: Branden Archer, zsh-workers
On Jun 13, 3:32pm, 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.
I believe this is because zsh supports having nul-bytes in parameter
values, whereas bash treats the nul as terminating the string. This
is not something we can (or I think want) to special-case for file
paths.
Those files in /sys are documented to contain strings separated by
nul bytes, so as soon as you read one with "cat" you have already
made a coding error. Instead you should be doing something like
read -d $'\0' -E < location
Conversely, this --
} root~# echo "hi" > sub$(cat location)/myfile
} zsh: is a directory: subdir
-- probably is a bug, just not the bug you think it is; the error should
be that "subdir\0" is an illegal file name, rather than terminating the
path at the nul and botching the redirection.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Issue with resolving paths with zsh using \0 in variables
2017-06-14 23:02 ` Bart Schaefer
@ 2017-06-15 3:40 ` Eric Cook
2017-06-15 4:13 ` Bart Schaefer
2017-06-15 4:22 ` Bart Schaefer
0 siblings, 2 replies; 6+ messages in thread
From: Eric Cook @ 2017-06-15 3:40 UTC (permalink / raw)
To: zsh-workers
On 06/14/2017 07:02 PM, Bart Schaefer wrote:
> -- probably is a bug, just not the bug you think it is; the error should
> be that "subdir\0" is an illegal file name, rather than terminating the
> path at the nul and botching the redirection.
>
I think it is correct, since \0 is in IFS, word splitting happens since the command substitution
isn't quoted. Since zsh will sent the output of a command to multiple destinations if the result
of an expansion is multiple words, it zsh tries to send the output to dir/ and /myfile; but
fails hard when it can't write to dir/, not attempting to write to /myfile.
When the expansion is quoted, you do get the error that you think it should have.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Issue with resolving paths with zsh using \0 in variables
2017-06-15 3:40 ` Eric Cook
@ 2017-06-15 4:13 ` Bart Schaefer
2017-06-15 4:22 ` Bart Schaefer
1 sibling, 0 replies; 6+ messages in thread
From: Bart Schaefer @ 2017-06-15 4:13 UTC (permalink / raw)
To: zsh-workers
On Jun 14, 11:40pm, Eric Cook wrote:
}
} On 06/14/2017 07:02 PM, Bart Schaefer wrote:
}
} > -- probably is a bug, just not the bug you think it is; the error should
} > be that "subdir\0" is an illegal file name, rather than terminating the
} > path at the nul and botching the redirection.
}
} When the expansion is quoted, you do get the error that you think it
} should have.
No, I don't:
torch% echo "hi" > "sub$(cat location)/myfile"
zsh: is a directory: subdir^@/myfile
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Issue with resolving paths with zsh using \0 in variables
2017-06-15 3:40 ` Eric Cook
2017-06-15 4:13 ` Bart Schaefer
@ 2017-06-15 4:22 ` Bart Schaefer
1 sibling, 0 replies; 6+ messages in thread
From: Bart Schaefer @ 2017-06-15 4:22 UTC (permalink / raw)
To: zsh-workers
On Jun 14, 11:40pm, Eric Cook wrote:
}
} ... since \0 is in IFS, word splitting happens since the command
} substitution isn't quoted.
This is happening, though, I didn't mean to imply otherwise.
} zsh tries to send the output to [subdir] and /myfile; but fails hard when
} it can't write to [subdir], not attempting to write to /myfile.
This bothers me a little bit as well, actually, though probably there
is nothing to be done about it, since there's no way to validate all
the attempted redirections at once.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-06-15 4:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-13 19:32 Issue with resolving paths with zsh using \0 in variables Branden Archer
2017-06-14 0:38 ` Eric Cook
2017-06-14 23:02 ` Bart Schaefer
2017-06-15 3:40 ` Eric Cook
2017-06-15 4:13 ` Bart Schaefer
2017-06-15 4:22 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).