Hello, the screenshot says it all: http://psprint.blinkenshell.org/weird.png In the while loop, $__tmp[-1] returns correct data. After the loop, $__tmp[-1] nor $__tmp[@] contain any data. More: when I provide the data (on the writing end) in following way: print -r -- "${(q)ZTSMAP[colsearch_pattern]}"$'\0' print -nr -- "${(j::)${__zts_hcw_found[@]/(#e)/--${num}-del--}}" Then the issue occurs. But when I'll do it in following way: print -nr -- "${(q)ZTSMAP[colsearch_pattern]}"$'\0'"${(j::)${__zts_hcw_found[@]/(#e)/--${num}-del--}}" I.e. through write of a single string – then the after-loop $__tmp references contain correct data. What's going on? -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
Turned out the tricky output-parameter specifier, the '__tmp[(#__tmp + 1)]' isn't correct. Apparently because #__tmp in math context is character-code. Regular __tmp_size variable and '__tmp[__tmp_size + 1]' works correctly, even when the data is printed in two print -r instructions, not as the single string. On Sat, 27 Oct 2018 at 22:35, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > > Hello, > the screenshot says it all: > http://psprint.blinkenshell.org/weird.png > > In the while loop, $__tmp[-1] returns correct data. > > After the loop, $__tmp[-1] nor $__tmp[@] contain any data. > > More: when I provide the data (on the writing end) in following way: > > print -r -- "${(q)ZTSMAP[colsearch_pattern]}"$'\0' > print -nr -- "${(j::)${__zts_hcw_found[@]/(#e)/--${num}-del--}}" > > Then the issue occurs. But when I'll do it in following way: > > print -nr -- > "${(q)ZTSMAP[colsearch_pattern]}"$'\0'"${(j::)${__zts_hcw_found[@]/(#e)/--${num}-del--}}" > > I.e. through write of a single string – then the after-loop $__tmp > references contain correct data. What's going on? > > -- > Sebastian Gniazdowski > News: https://twitter.com/ZdharmaI > IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin > Blog: http://zdharma.org -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
On Sat, Oct 27, 2018 at 1:53 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> Turned out the tricky output-parameter specifier, the '__tmp[(#__tmp +
> 1)]' isn't correct. Apparently because #__tmp in math context is
> character-code. Regular __tmp_size variable and '__tmp[__tmp_size +
> 1]' works correctly, even when the data is printed in two print -r
> instructions, not as the single string.
You could also do __tmp[$#__tmp+1] if you want to avoid the extra variable.
On Sun, 28 Oct 2018 at 06:22, Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Sat, Oct 27, 2018 at 1:53 PM Sebastian Gniazdowski > <sgniazdowski@gmail.com> wrote: > > > > Turned out the tricky output-parameter specifier, the '__tmp[(#__tmp + > > 1)]' isn't correct. Apparently because #__tmp in math context is > > character-code. Regular __tmp_size variable and '__tmp[__tmp_size + > > 1]' works correctly, even when the data is printed in two print -r > > instructions, not as the single string. > > You could also do __tmp[$#__tmp+1] if you want to avoid the extra variable. Thanks, didn't try this. The extra variable has additional positive effect – when increased for each 0 return from sysread, it doesn't compute array length each read. But for 65kB reads, it probably doesn't matter, as there will not be many of reads at all (to exhaust the input FD). Blinkenshell isn't responding, a more permanent and responsive link: https://imgur.com/YGWYTLe -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org