| Ticket UUID: | 845241 | ||
| Title: | Unsetting env vars in slave interps | ||
| Type: | Bug | Created on: | 2003-11-19 16:43:19 |
| Submitter: | sbron | Assigned to: | jan.nijtmans |
| Subsystem: | 08. Environment Variables | Severity: | Minor |
| Priority: | 5 Medium | Last modified: | 2026-10-30 13:08:19 |
| Status: | Closed | Closed by: | jan.nijtmans |
| Resolution: | Fixed | Closed on: | 2026-10-30 13:08:19 |
| Version: | 8.6.18, 9.0.5, 9.1.0 | ||
| Description: | ||||
When an evironment variable has been unset in a slave
interpreter it is left in some strange state:
- info exists reports the variable still exists
- set and $env report the variable doesn't exist
- using an upvar alias the variable still has its
original value
Tested on Linux 2.4.20 and windows 98.
Code to reproduce the problem (use some existing
environment variable):
puts $env(SHELL)
interp create i
i eval {unset env(SHELL)}
catch {set env(SHELL)} msg
puts $msg
puts [info exists env(SHELL)]
upvar 0 env(SHELL) foo
puts $foo
| ||||
| User Comments: | ||||
serhiy.storchaka added on 2026-10-19 18:15:22:
Still present in 8.6, 9.0 and 9.1: after a child interp unsets an env variable, [info exists env(X)] stays 1 in the parent. Proposed fix in branch env-stale-element, together with [3602289fff] and [67fd4f973a]: the read trace removes the stale element. Test env-11.1. jan.nijtmans added on 2026-10-30 13:08:19:
Fixed in [1f1167cd23|trunk], core-9-0-branch and core-8-6-branch Many thanks! | ||||