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.




Reply via email to