Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib - Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash- N2nMjo/bash-4.4.18=. -fstack-protector-strong -Wformat -Werror=format- security -Wall -Wno-parentheses -Wno-format-security uname output: Linux Precision 4.15.0-70-generic #79-Ubuntu SMP Tue Nov 12 10:36:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4 Patch Level: 20 Release Status: release Description: 'in' is a builtin command and is not listed in the man page as such. Repeat-By: type at the bash command line: $ in bash: syntax error near unexpected token `in' $ which in $ Or how I found out about this issue (I did not test the below): $ cd $ mkdir bin $ PATH=$HOME/bin:$PATH $ echo 'echo test in script' | tee -a ~/bin/in $ chmod 755 ~/bin/in $ which in /home/user/bin/in $ in bash: syntax error near unexpected token `in' $ Then, test the script does work just fine $ ./in test in script $ Why is this bug report important? Why change the man page? I wasted 20 minutes of my time, to prove to my satisfaction that 'in' was not invoking my script at all. Search engines did not find a match to the error message. I can not imagine this report is the first time this bug was found.