Date: Mon, 30 May 2022 22:10:58 +0000 From: bugzilla-noreply@freebsd.org To: standards@FreeBSD.org Subject: [Bug 46441] sh(1): Does not support PS1, PS2, PS4 parameter expansion Message-ID: <bug-46441-99-ji3FHhzaIr@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-46441-99@https.bugs.freebsd.org/bugzilla/> References: <bug-46441-99@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D46441 --- Comment #15 from Jilles Tjoelker <jilles@FreeBSD.org> --- (In reply to Piotr Pawel Stefaniak from comment #13) If you're creating a parser state struct, it may be better to pass a pointe= r to it to most functions in parser.c. The struct would be allocated on the stac= k in parsecmd(), parsewordexp() and expandstr(). This eliminates uncertainty abo= ut "which" parser state needs to be used. Due to pointers in the parser state that need to be freed, parsecmd() and parsewordexp() would need to use setjmp(). An alternative might be to keep = the parser state for those statically allocated; I don't think they are re-ente= red (eval and . are not among the builtins that can execute in a subshell witho= ut a fork). To avoid unlimited recursion via PS4 while still allowing command substitut= ion in expandstr(), it might work better to ignore xflag during an expandstr() invocation. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-46441-99-ji3FHhzaIr>