Re: mapfile and proc filesystem, limitation or possible bug

On Tue, Jun 23, 2026 at 12:52=E2=80=AFAM Jim <[email protected]> wro=
te:
>
> Hello,
>
> ZSH_VERSION:  5.9.1
>
> Is there a limitation with mapfile when it comes to the proc filesystem o=
r is there a bug?
> In a normal directory like $HOME the following work as expected:
>
> %  cd $HOME
> %  print ${(ok)mapfile)
>   outputs all names
> %  [[ -v mapfile[.zshrc] ]] && print Found || print Not Found
>   outputs:  Found
> %  array=3D("${(f@)${mapfile[.zshrc]%$=E2=80=99\n=E2=80=99}}")
>   array is populated
>
> In a proc directory it does not
>
> %  cd /proc/$$
> %  print ${(ok)mapfile)
>   outputs all names as expected
> %  [[ -v mapfile[status] ]] && print Found || print Not Found
>   outputs:  Not Found
> %  array=3D("${(f@)${mapfile[status]%$=E2=80=99\n=E2=80=99}}")
>   array contains one empty element
>
> The man page lists a number of mapfile LIMITATIONS, but I didn't see anyt=
hing that I
> interpreted as the proc filesystem. If it is a limitation should somethin=
g more clear be
> added to the manpage?
>
> There are other ways of checking files and getting data from the proc fil=
es, but I was
> hoping to determine why mapfile doesn't work.
>
> % print ${(t)mapfile}  -> association-hide-hideval-special
> % print ${(t)commands} -> association-hide-hideval-special
>
> The above both have the same keywords defining them, and still outputs as=
 expected.
> % [[ -v commands[nvim] ]] && print Found || print Not Found
>   outputs Found
>
> The only difference I can tell, from my previous examples with mapfile, i=
s different
> filesystem types.
>
> Any clarification would be appreciated.

Files in /proc tend to have a reported size of 0 bytes, and the
mapfile module uses stat to see how big to make the buffer for mmap,
which in this case obviously turns out to be 0. If you disable the
mmap path, it uses ftell(..., SEEK_END) to size the buffer to read
into, which also ends up as 0; no data for you.


--
Mikael Magnusson