[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ${| command; } funsub not setting REPLY does not error out with 'set
From: |
Zachary Santer |
Subject: |
Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active |
Date: |
Fri, 20 Dec 2024 13:01:03 -0500 |
On Fri, Dec 20, 2024 at 11:50 AM Greg Wooledge <greg@wooledge.org> wrote:
>
> On Fri, Dec 20, 2024 at 11:04:35 -0500, Zachary Santer wrote:
> > On Thu, Dec 19, 2024 at 11:08 AM Chet Ramey <chet.ramey@case.edu> wrote:
> > > So you're saying that bash looking at a specific variable and using its
> > > value should fail if that variable is unset? How far do you want to
> > > take that? PS2? PS4? GLOBIGNORE? COMPREPLY?
> >
> > Explicitly attempting to expand any one of those with a parameter
> > expansion when it's unset and 'set -u' is active will cause bash to
> > error out. ${| command; } is likewise also an explicit attempt to
> > expand the value of a variable, this time the instance of REPLY local
> > to the funsub.
>
> I don't think your definition of "explicit" matches mine.
${variable} and ${| command; } are explicit expansions in the sense
that I had to write them in the script for the expansions they specify
to be performed. As opposed to PS2, which bash will happily expand
without the user having to type ${PS2} anywhere.
> > So the purpose of 'set -u' still applies. If I, as the programmer,
> > managed to misspell REPLY or forget to set it in some codepath, I'd
> > rather bash tell me that than have it silently expand ${| command; }
> > to nothing
>
> I suppose that makes sense to the kind of person who'd use set -u in
> the first place. However, a great number of shell functions don't
> "return" anything (here, I'm talking about traditional ones, where the
> "return value" is written to stdout to be captured in a command sub).
> I don't think it makes sense for a script to error out by default if
> a funsub expands to nothing, even when set -u is in effect. The odds
> of the abort being undesirable there seem quite high.
I'm not saying anything about ${ command; }. My comments are specific
to the ${| command; } form. I agree that if what's present within ${
command; } doesn't output anything, that shouldn't trip 'set -u'.
- ${| command; } funsub not setting REPLY does not error out with 'set -u' active, Zachary Santer, 2024/12/18
- Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active, Lawrence Velázquez, 2024/12/18
- Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active, Chet Ramey, 2024/12/19
- Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active, Zachary Santer, 2024/12/20
- Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active, Greg Wooledge, 2024/12/20
- Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active,
Zachary Santer <=
- Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active, Martin D Kealey, 2024/12/20
- Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active, Chet Ramey, 2024/12/23
- Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active, Zachary Santer, 2024/12/24
- Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active, Lawrence Velázquez, 2024/12/24
- Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active, Zachary Santer, 2024/12/25
- Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active, microsuxxor, 2024/12/25