Hierarchical data (was: Light weight support for JSON)
On Wed, Aug 31, 2022 at 11:11:26AM -0400, Chet Ramey wrote: On 8/29/22 2:03 PM, tetsu...@scope-eye.net wrote: It would also help greatly if the shell could internally handle hierarchical data in variables. That's a fundamental change. There would have to be a better reason to make it than handling JSON. I've only a little interest in handling JSON natively in bash (jq usually gets me there), but I have a strong interest in handling hierarchical data (h-data) in bash. I admit I've only had a few cases where I've been jumping through hoops to manage h-data in bash, but that's because, once it's clear h-data is a natural way to manage an issue, I would normally handle the problem in perl rather than trying to force clunky constructs into a bash script. In perl I use h-data all the time. I'm sure if h-data were available in bash I'd be using it all the time there as well. Chris
File descriptor leak
From: ch...@onthe.net.au To: bug-bash@gnu.org Subject: File descriptor leak Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux b2 5.7.9-otn-3-g8c0bb49bc11c #1 SMP Fri Jul 17 04:37:20 UTC 2020 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 3 Release Status: release Description: Bash is leaking a file descriptor. Repeat-By: -- #!/bin/bash if : then while read l do grep . /proc/$$/fdinfo/* pvs > /dev/null done < <( echo ) echo fi -- The script generates output like: /proc/2320431/fdinfo/0:pos: 0 /proc/2320431/fdinfo/0:flags: 010 /proc/2320431/fdinfo/0:mnt_id: 10 /proc/2320431/fdinfo/1:pos: 0 /proc/2320431/fdinfo/1:flags: 02 /proc/2320431/fdinfo/1:mnt_id: 20 /proc/2320431/fdinfo/10:pos:0 /proc/2320431/fdinfo/10:flags: 0202 /proc/2320431/fdinfo/10:mnt_id: 20 /proc/2320431/fdinfo/2:pos: 0 /proc/2320431/fdinfo/2:flags: 02 /proc/2320431/fdinfo/2:mnt_id: 20 /proc/2320431/fdinfo/255:pos: 123 /proc/2320431/fdinfo/255:flags: 0210 /proc/2320431/fdinfo/255:mnt_id:22 grep: /proc/2320431/fdinfo/3: No such file or directory /proc/2320431/fdinfo/63:pos:0 /proc/2320431/fdinfo/63:flags: 00 /proc/2320431/fdinfo/63:mnt_id: 10 File descriptor 63 (pipe:[189620647]) leaked on pvs invocation. Parent PID 2320431: /bin/bash The last 'echo' within the 'if' is required to trigger the error. The 'grep' is just to see the open file descriptors at that point, it's not required to trigger the bug. The 'pvs' (part of the lvm2 Logical Volume Manager suite) is also not required to trigger the bug, it's just how I noticed the bug. The lvm2 stuff is particularly loud about file descriptor leaks. Oh. Huh. I just noticed this also reproduces the problem: -- # pvs < <(echo) > /dev/null File descriptor 63 (pipe:[190051752]) leaked on pvs invocation. Parent PID 204155: -bash -- This version of the problem may be subtly different because as previously noted the first reproducer script requires the 'echo' within the 'if'. See also: - https://lists.gnu.org/archive/html/bug-bash/2017-01/msg00026.html - https://github.com/lvmteam/lvm2/blob/e10f20bc23088a2f9f7529f8f2b40d9c1fcb54c6/tools/lvmcmdline.c#L -- Chris Dunlop
