Re: Surprising behavior with inline environment variable expansion

2025-04-05 Thread Andreas Schwab 
On Mär 31 2025, Chet Ramey wrote:

> It's hard to see these as being useful if they're glibc-specific.

They are coming from ISO TR 14652 and 30112.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Is this a bug?

2025-04-05 Thread George R Goffe 
Howdy,

This system is a Fedora 42 x86_64 system.

I've been trying to build bash from a repository 
"https://git.savannah.gnu.org/git/bash.git"; and a having the devil's own time 
in the process.

Did I just catch the repository in the middle of a rework? I have a full log of 
the build process if it's needed. The failure appears with the nonexperimental 
GCC as well as a version I built a few days ago from their repository. 
gcc-15.0.1-0.9.fc42.x86_64 or gcc (GCC) 15.0.1 20250320 (experimental).

I'm seeing a TON of messages like these, am I doing something wrong?

Best regards,

George...

    836 make[1]: Entering directory '/export/home/tools/bash/bash/builtins'
    837 rm -f mkbuiltins.o
    838 gcc -c  -DHAVE_CONFIG_H -DSHELL  -I. -I..  -I.. -I../include -I../lib 
-I. -I../lib/intl -I/tools/bash/b    838 ash/lib/intl -Wno-parentheses 
-Wno-format-security   -g -O2  mkbuiltins.c
    839 mkbuiltins.c: In function ‘main’:
    840 mkbuiltins.c:232:1: warning: old-style function definition 
[-Wold-style-definition]
    841   232 | main (argc, argv)
    842   | ^~~~
    843 mkbuiltins.c:267:29: error: too many arguments to function ‘xmalloc’; 
expected 0, have 1
    844   267 |   error_directory = xmalloc (2 + strlen 
(argv[arg_index]));
    845   | ^~~  

    846 mkbuiltins.c:62:14: note: declared here
    847    62 | static char *xmalloc (), *xrealloc ();
    848   |  ^~~
    849 mkbuiltins.c:307:34: error: too many arguments to function ‘xmalloc’; 
expected 0, have 1
    850   307 |   temp_struct_filename = xmalloc (15);

Re: Surprising behavior with inline environment variable expansion

2025-04-05 Thread Andreas Schwab 
On Mär 26 2025, Andreas Kähäri wrote:

> The argument to "bash -c"

There is no "bash -c" in that command.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: ;exit in bash history causes bash to exit

2025-04-05 Thread Ethan Gascoigne 
I do have an alias with `&& exit` in it, but removing that alias
doesn't get rid of the bug. I've tested it on another system (Xubuntu
24.04, stock install), and the issue didn't occur.

Narrowed it down to the line `eval "$(fasd --init auto)"` in my
.bashrc. Must be some kindof bug with fasd
(https://github.com/whjvenyl/fasd). Any idea how fasd could cause
`;exit` to be interpreted as a valid command? Running `alias exit`
shows that it's not aliased to anything.

Weird that fasd causes `;exit` to be a valid command, and also that it
causes bash to execute it when loading if it's the last thing in the
history file. I'll raise a bug report on the fasd GitHub. Apologies
for the erroneous report.

Cheers,
Ethan



On Tue, 25 Mar 2025 at 20:24, Martin Schulte  wrote:
>
> Hello Ethan,
>
> I can't reproduce the problem:
>
> > Repeat-By:
> > Open a terminal with bash as the shell
> > Type `;exit`
>
> This results in
>
> bash: syntax error near unexpected token `;'
>
> but not in closing the shell.
>
> > Re-open the terminal, it will immediately close
>
> Is there maybe something broken in your setup?
>
> Best regards,
>
> Martin

2.0..devel: `set -u; a=1; echo ${#a[@]}' fails

2025-04-05 Thread Koichi Murase 
With nounset, ${#a[@]} for a scalar variable fails even though we can
correctly obtain the result (which is consistent with the expansion of
"${a[@]}") without nounset.  This is the result with the devel
version:

  $ bash -c 'a=1; echo ${#a[@]}'
  1
  $ bash -uc 'a=1; echo ${#a[@]}'
  bash: line 1: a: unbound variable

This behavior seems to be present from the very beginning
implementation of arrays in bash-2.0:

  $ bash-2.0 -c 'a=1; echo ${#a[@]}'
  1
  $ bash-2.0 -uc 'a=1; echo ${#a[@]}'
  bash-2.0: a: unbound variable

However, this behavior does not match that of other shells:

  $ ksh -c 'a=1; echo ${#a[@]}'
  1
  $ ksh -uc 'a=1; echo ${#a[@]}'
  1

  $ mksh -c 'a=1; echo ${#a[@]}'
  1
  $ mksh -uc 'a=1; echo ${#a[@]}'
  1

  $ zsh -c 'a=1; echo ${#a[@]}'
  1
  $ zsh -uc 'a=1; echo ${#a[@]}'
  1

Is this intentional?  If so, how can I understand the mental model or
the design background?  I'd be happy if the current behavior is fixed.

--
Koichi