Skip site navigation (1)Skip section navigation (2)
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>