lkml.org 
[lkml]   [2018]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 11/23] kconfig: add 'shell-stdout' function
    On Mon, Feb 19, 2018 at 10:01:49AM -0800, Linus Torvalds wrote:
    > On Mon, Feb 19, 2018 at 9:44 AM, Linus Torvalds
    > <torvalds@linux-foundation.org> wrote:
    > >
    > > I do like your "success"/"stdout" more than "shell"/"shell-stdout",
    > > because with that naming I don't get the feeling that one should
    > > subsume the other.
    >
    > Hmm. Thinking about it some more, I really would prefer just "$(shell
    > ...)" everywhere.
    >
    > But it would be nice if perhaps the error handling would match the
    > context somehow.
    >
    > I'm wondering if this might tie into the whole quoting discussion in
    > the other thread.
    >
    > Because the rule could be:
    >
    > (a) unquoted $(shell ) is a bool, and failing is ok (and turns into
    > y/n depending on whether successful or failing)
    >
    > So
    >
    > config CC_IS_GCC
    > bool
    > default $(shell $CC --version | grep -q gcc)
    >
    > works automatically.
    >
    > (b) but with quoting, $(shell ) is a string, and failing is an error
    >
    > So
    >
    > config GCC_VERSION
    > int
    > default "$(shell-stdout $srctree/scripts/gcc-version.sh $CC
    > | sed 's/^0*//')" if CC_IS_GCC
    > default 0
    >
    > would need those quotes, and if the shell-script returns a failure,
    > we'd _abort_.
    >
    > Which is actually what we want there.
    >
    > Hmm? Is that too nasty?
    >
    > Linus

    One minor drawback would be slight kludginess if you want "n"/"y" put
    into a string depending on the success of a command:

    default "foo-$(shell cmd && echo y || echo n)"

    As opposed to:

    default "foo-$(success cmd)"

    I don't know if that's significant enough to matter in practice.

    Keeping it objective, I can't see any major downsides, though I'd really
    prefer to just have $() do string interpolation within "". That keeps
    the implementation trivial and makes the behavior and limitations
    obvious once you know that n/m/y is just shorthand for "n"/"m"/"y".

    Cheers,
    Ulf

    \
     
     \ /
      Last update: 2018-02-19 19:55    [W:4.214 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site