Bash – undocumented change of behaviour of ‘local’ builtin in bash 4.3

bash

In bash 4.2, a variable declared as local to a function but without a default value nontheless enters the list of variables – at least as far as 'declare -p' is concerned:

vermicelli$ bash --version | grep release
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
vermicelli$ bash -c 'f1() { local Y; declare -p Y; }; f1'
declare -- Y
vermicelli$

However, in bash 4.3 this is no longer the case:

lasagne$ bash --version | grep release
GNU bash, version 4.3.46(1)-release (x86_64-pc-linux-gnu)
lasagne$ bash -c 'f1() { local Y; declare -p Y; }; f1'
bash: line 0: declare: Y: not found
lasagne$

Is this change of behaviour documented anywhere?

If a default value is provided (e.g. change 'local Y' to 'local Y=42') then both bash versions behave the same.

(I've checked bash 4.3's man page, particularly the paragraphs dealing with the declare and local builtins, the shopt option compat42, as well as the FAQ, particularly the paragraph dealing with what's new in 4.3, but I don't find any mention of this change in behaviour.)

Best Answer

Excerpts from the bash changelog:

This document details the changes between this version, bash-4.4-alpha, and the previous version, bash-4.3-release.

3. New Features in Bash

f. The -p option to declare and similar builtins will display attributes for named variables even when those variables have not been assigned values (which are technically unset).

This document details the changes between this version, bash-4.3-alpha, and the previous version, bash-4.2-release.

1. Changes to Bash

hhhh. Fixed a bug that caused declare and test to find variables that had been given attributes but not assigned values. Such variables are not set.

Note that local is just an alias for declare, except that local errors out when it isn't called inside a function.

It looks like having typeset -p list unset variables was considered a bug, but then the behavior was reverted because having declare -p list such variables is “a common enough request”.

Related Question