Re: mapfile and unset: Does this actually work?

["Mark J. Reed" <markjreed@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

I take that back. If the file is nonempty, then the file is deleted. If the
file is empty, then it's not. So it seems to be an conflation of unset and
empty in the mapfile logic.

On Sun, Feb 4, 2024 at 12:57 PM Mark J. Reed <markjreed@gmail.com> wrote:

> FWIW this seems to be a regression introduced in your development branch.
> Using the 5.9 release, *unset 'mapfile[removable]'*  does indeed delete
> the file. I tested on macOS, Windows+msys2, and Ubuntu.
>
>
> On Sat, Feb 3, 2024 at 11:25 PM Bart Schaefer <schaefer@brasslantern.com>
> wrote:
>
>> If we're contemplating a release, does anyone else want to eyeball this?
>>
>> On Sun, Jan 21, 2024 at 6:05 PM Bart Schaefer <schaefer@brasslantern.com>
>> wrote:
>> >
>> > Doc says:
>> >
>> > mapfile
>> >      This associative array takes as keys the names of files; the
>> >      resulting value is the content of the file.  The value is treated
>> >      identically to any other text coming from a parameter.  The value
>> >      may also be assigned to, in which case the file in question is
>> >      written (whether or not it originally existed); or an element may
>> >      be unset, which will delete the file in question.
>> >
>> > However:
>> >
>> > % touch removable
>> > % zmodload zsh/mapfile
>> > % : $mapfile[removable] ; unset 'mapfile[removable]'
>> > % ls -l removable
>> > -rw-rw-r-- 1 schaefer schaefer 0 Jan 21 17:17 removable
>> >
>> > I tried several variations of this and I can't get mapfile to remove
>> anything.
>>
>> I still haven't worked out what's going on here.
>>
>>
>
> --
> Mark J. Reed <markjreed@gmail.com>
>


-- 
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 2871 bytes --]