bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [mapfile]: problem reentrance with normal file


From: Didou Serge
Subject: Re: [mapfile]: problem reentrance with normal file
Date: Mon, 12 Nov 2018 18:47:55 +0100

But not work under linux...

Le lun. 12 nov. 2018 à 17:00, Didou Serge <address@hidden> a écrit :

> I tested with another configuration and ALL work fine:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: cygwin
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='x86_64-unknown-cygwin'
> -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS   -I.
> -I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4
> -I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4/include
> -I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4/lib  -DWORDEXP_OPTION -ggdb
> -O2 -pipe -Wimplicit-function-declaration
> -fdebug-prefix-map=/usr/src/bash-4.4.12-3.x86_64/build=/usr/src/debug/bash-4.4.12-3
> -fdebug-prefix-map=/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4=/usr/src/debug/bash-4.4.12-3
> -Wno-parentheses -Wno-format-security
> uname output: CYGWIN_NT-6.1 EB-5CG63201SJ 2.8.0(0.309/5/3) 2017-04-01
> 20:47 x86_64 Cygwin
> Machine Type: x86_64-unknown-cygwin
>
> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
>
>
>
> Le lun. 12 nov. 2018 à 16:48, Didou Serge <address@hidden> a
> écrit :
>
>> Ok, in this case, this should not work either:
>>
>> mapfile -C xx -c 1 UU  < <( echo -e "Premiere ligne" A{1..45}
>> "\nDeuxieme ligne" B{1..45} "\nTroisieme ligne" C{1..45})
>>
>> But, this form work fine.
>>
>> Le lun. 12 nov. 2018 à 15:44, Chet Ramey <address@hidden> a écrit :
>>
>>> On 11/11/18 3:32 PM, Didou Serge wrote:
>>>
>>> > Bash Version: 4.4
>>> > Patch Level: 7
>>> > Release Status: release
>>> >
>>> > Description:
>>> > When use mapfile from normal file that call function that use mapfile,
>>> the
>>> > first mapfile lost data.
>>> >
>>> > Repeat-By:
>>> > I create 3 functions:
>>> > ww(){ echo "$@" | mapfile -C yy -c 1 -t TT ; }
>>> > xx(){ mapfile -C yy -c 1 -t TT < <(echo "$@") ; }
>>> > yy(){ echo "$@" ;}
>>> >
>>> > I create 1 normal file:
>>> > echo -e "Premiere ligne" A{1..45} "\nDeuxieme ligne" B{1..45}
>>> "\nTroisieme
>>> > ligne" C{1..45} >fic.txt
>>> >
>>>         [...]
>>> > This not work (lost data in second line and after) :
>>> > mapfile -C xx -c 1 UU <fic.txt
>>> > 0 0 Premiere ligne A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15
>>> A16
>>> > A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27 A28 A29 A30 A31 A32 A33
>>> A34 A35
>>> > A36 A37 A38 A39 A40 A41 A42 A43 A44 A45
>>> > 0 1  B17 B18 B19 B20 B21 B22 B23 B24 B25 B26 B27 B28 B29 B30 B31 B32
>>> B33
>>> > B34 B35 B36 B37 B38 B39 B40 B41 B42 B43 B44 B45
>>> > 0 2 ligne C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 C16 C17
>>> C18
>>> > C19 C20 C21 C22 C23 C24 C25 C26 C27 C28 C29 C30 C31 C32 C33 C34 C35
>>> C36 C37
>>> > C38 C39 C40 C41 C42 C43 C44 C45
>>>
>>> This is a buffering issue caused by nested calls to mapfile in the same
>>> process. The first call to mapfile reads a bufferful of data from the
>>> input file, and the second mapfile (the one executed as part of the
>>> callback) reads data into that same buffer. When the second call
>>> finishes,
>>> and the first mapfile is called again, the remaining characters in the
>>> buffer have already been discarded. It's not safe to call mapfile as part
>>> of a callback to a mapfile invocation.
>>>
>>> Chet
>>> --
>>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>>                  ``Ars longa, vita brevis'' - Hippocrates
>>> Chet Ramey, UTech, CWRU    address@hidden
>>> http://tiswww.cwru.edu/~chet/
>>>
>>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]