Re: When "set -u", "which" outputs environment: line 1: _declare: unbound

2021-04-09 Thread Lawrence Velázquez
On Fri, Apr 9, 2021, at 4:51 PM, Eli Schwartz wrote: > Are you ready to have your day truly spoiled? Fedora's package for the > external program GNU which, provides this /etc/profile.d/ script > (automatically injected into the environment of any interactive shell > sessions once you install GNU wh

Re: When "set -u", "which" outputs environment: line 1: _declare: unbound

2021-04-09 Thread Eli Schwartz
On 4/9/21 4:22 PM, Greg Wooledge wrote: > On Fri, Apr 09, 2021 at 03:08:25PM -0400, Craig Andrews wrote: >> Description: >> With "set -u", invoking "which" results in the output of: >> environment: line 1: _declare: unboundvariable >> That should not happen, and does not happen, wit

Re: When "set -u", "which" outputs environment: line 1: _declare: unbound

2021-04-09 Thread Chet Ramey
On 4/9/21 3:08 PM, Craig Andrews wrote: Bash Version: 5.1 Patch Level: 0 Release Status: release Description:     With "set -u", invoking "which" results in the output of: environment: line 1: _declare: unboundvariable     That should not happen, and does not happen, with prior versi

Re: When "set -u", "which" outputs environment: line 1: _declare: unbound

2021-04-09 Thread Greg Wooledge
On Fri, Apr 09, 2021 at 03:08:25PM -0400, Craig Andrews wrote: > Description: > With "set -u", invoking "which" results in the output of: > environment: line 1: _declare: unboundvariable > That should not happen, and does not happen, with prior versions of > bash. > I'm usin

Re: When "set -u", "which" outputs environment: line 1: _declare: unbound

2021-04-09 Thread konsolebox
On Sat, Apr 10, 2021 at 4:08 AM Craig Andrews wrote: > Repeat-By: > Run this shell script: > #!/bin/bash > set -u > echo "$(which bash)" Tested with vanilla bash 5.1.0 it works well with `/bin/bash` as output. Maybe one of your builtins or external commands is

When "set -u", "which" outputs environment: line 1: _declare: unbound

2021-04-09 Thread Craig Andrews
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs

Re: Changing the way bash expands associative array subscripts

2021-04-09 Thread konsolebox
On Fri, Apr 9, 2021 at 8:17 PM Greg Wooledge wrote: > How can you look at that code and call it anything other than a hack? > It's a piece of pure desperation. You can only READ the array, not write > to it. You can't do an index iteration, either -- only a value iteration. > And you still have

Re: Changing the way bash expands associative array subscripts

2021-04-09 Thread Koichi Murase
.2021年4月9日(金) 23:53 Chet Ramey : > On 4/8/21 6:23 PM, Koichi Murase wrote: > > I currently don't have any better idea, but in that way, it seems to > > me that there is no way to represent a reference to an element > > associated with key=@ under the new `assoc_expand_once', which was > > what I wa

Re: Changing the way bash expands associative array subscripts

2021-04-09 Thread Chet Ramey
On 4/8/21 6:23 PM, Koichi Murase wrote: I currently don't have any better idea, but in that way, it seems to me that there is no way to represent a reference to an element associated with key=@ under the new `assoc_expand_once', which was what I wanted to argue in my previous reply. Under wh

Re: Changing the way bash expands associative array subscripts

2021-04-09 Thread Greg Wooledge
On Fri, Apr 09, 2021 at 08:17:52AM +0800, konsolebox wrote: > On Fri, Apr 9, 2021 at 4:08 AM Greg Wooledge wrote: > > But apparently someone stumbled upon this trick, and passed it around, > > and now there's a whole subculture of people who use this as a hack for > > trying to pass array variable