[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0725ccc9abce84695573539c5f3d9d061384469d.camel@linuxfoundation.org>
Date: Thu, 18 Aug 2022 22:45:58 +0100
From: Richard Purdie <richard.purdie@...uxfoundation.org>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Randy Dunlap <rdunlap@...radead.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Sean Christopherson <seanjc@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] init/Kconfig: fix CC_HAS_ASM_GOTO_TIED_OUTPUT test with
dash
On Fri, 2022-08-19 at 04:31 +0900, Masahiro Yamada wrote:
> On Thu, Aug 18, 2022 at 6:14 PM Richard Purdie
> <richard.purdie@...uxfoundation.org> wrote:
> >
> > This problem is a little more subtle.
> >
> > As far as I could work out, exec() is used on entries like this in
> > kConfig. exec() falls back to /bin/sh so it is hard to see where this
> > would be changed to be /bin/bash.
>
>
>
> Kconfig uses popen() to execute a shell command.
>
> See do_shell() in scripts/kconfig/preprocess.c
>
> popen(3) says that
> "the command is passed to /bin/sh using the -c flag.
> interpretation, if any, is performed by the shell."
>
> GNU Make is the same.
> Make uses /bin/sh to execute commands in
> recipe lines and $(shell ...) functions.
> You can change the default shell via 'SHELL' variable.
That makes sense. I don't think we can easily change the shell popen()
uses.
>
> BTW, Richard is here, so let me ask about BitBake.
>
> The manual [3] clearly says:
>
> "When you create these types of functions in your recipe or class files,
> you need to follow the shell programming rules. The scripts are
> executed by /bin/sh,
> which may not be a bash shell but might be something such as dash.
> You should not use Bash-specific script (bashisms)"
>
> I just thought BitBake ran shell code in bash before,
> but I might have misunderstood.
> Do OE/Yocto allow only POSIX shell code?
Bitbake runs shell code with /bin/sh so we don't allow bashisms and
that has always been the case.
Like this case in the kernel, we do get people submitting changes which
were only tested with bash which can be frustrating but the manual and
our policy is quite clear. We just fix any that do creep through and
have test systems that have dash to try and catch them too.
Cheers,
Richard
Powered by blists - more mailing lists