`&>' doesn't behave as expected in POSIX mode
$ set -o posix $ uname &>/dev/null $ `uname &' and `>/dev/null' should be parsed as two separate commands; that, if I'm not missing anything, is what POSIX says. But bash doesn't do that in POSIX mode, and redirects both stderr and stdout to `/dev/null'. Oğuz
Re: `&>' doesn't behave as expected in POSIX mode
On 20/06/2021 09:05 am, Oğuz wrote: $ set -o posix $ uname &>/dev/null $ `uname &' and `>/dev/null' should be parsed as two separate commands; that, if I'm not missing anything, is what POSIX says. But bash doesn't do that in POSIX mode, and redirects both stderr and stdout to `/dev/null'. Oğuz If you want to parse them as two separate commands, separate them. -- Chris Elvidge England
Re: `&>' doesn't behave as expected in POSIX mode
20 Haziran 2021 Pazar tarihinde Chris Elvidge yazdı: > On 20/06/2021 09:05 am, Oğuz wrote: > >> $ set -o posix >> $ uname &>/dev/null >> $ >> >> `uname &' and `>/dev/null' should be parsed as two separate commands; >> that, if I'm not missing anything, is what POSIX says. But bash >> doesn't do that in POSIX mode, and redirects both stderr and stdout to >> `/dev/null'. >> >> >> Oğuz >> >> >> > If you want to parse them as two separate commands, separate them. Yeah, that's not the point. > > -- > Chris Elvidge > England > > > -- Oğuz
Re: `&>' doesn't behave as expected in POSIX mode
On 6/20/21 6:30 AM, Chris Elvidge wrote: > On 20/06/2021 09:05 am, Oğuz wrote: >> $ set -o posix >> $ uname &>/dev/null >> $ >> >> `uname &' and `>/dev/null' should be parsed as two separate commands; >> that, if I'm not missing anything, is what POSIX says. But bash >> doesn't do that in POSIX mode, and redirects both stderr and stdout to >> `/dev/null'. >> >> >> Oğuz >> >> > > If you want to parse them as two separate commands, separate them. *Neither* behavior is similar to e.g. dash's behavior, or for that matter ksh. Both print the uname output after registering it as a backgrounded job (redirection does not get applied to the command itself). At any rate... are you suggesting the POSIX rules require a space here in order to distinguish the behavior? -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
When searching in command history, highlighting is missing the first character
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux work 5.11.0-18-generic #19-Ubuntu SMP Fri May 7 14:22:03 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 4 Release Status: release Description: When using ctrl-R to search in the command history, Bash highlights the searched string, but not its first character. Repeat-By: 1. Open Bash, and command: abcdef 2. Click Ctrl-R, and type: bcde Expected behavior: The command "abcdef" is shown on the command line, and "bcde" is highlighted. Observed behavior: The command "abcdef" is shown on the command line, and "cde" is highlighted.
Re: When searching in command history, highlighting is missing the first character
On Sun, Jun 20, 2021 at 07:51:03PM +0300, Teemu Leisti wrote: > Repeat-By: > 1. Open Bash, and command: abcdef > 2. Click Ctrl-R, and type: bcde > Expected behavior: The command "abcdef" is shown on the command line, > and "bcde" is highlighted. > Observed behavior: The command "abcdef" is shown on the command line, > and "cde" is highlighted. I believe what you're seeing is the result of the cursor still being on the "a". The cursor in my terminal (urxvt) is simply a reverse-video filter, exactly the same as the "highlighting" that you're getting from the reverse-i-search. The two reverses cancel each other out. If I move the mouse pointer out of the terminal in question and into a different window, the textual cursor goes away, and I can see the reverse-video highlighting on all the selected characters, including the "a". Your results may differ, depending on the type of terminal emulator you're using, and the window manager and its focus paradigm (mine is fvwm, set to use focus follows mouse). You might need to click a different window to transfer focus away from the terminal in which you're doing the reverse-i-search.
Re: `&>' doesn't behave as expected in POSIX mode
Oğuz writes: > $ set -o posix > $ uname &>/dev/null > $ > > `uname &' and `>/dev/null' should be parsed as two separate commands; > that, if I'm not missing anything, is what POSIX says. But bash > doesn't do that in POSIX mode, and redirects both stderr and stdout to > `/dev/null'. An interesting point! At least according to the 2018 edition, a Posix shell parses that command as uname & > /dev/null which is two commands, "uname &" and ">/dev/null". The second command is a no-op. Whereas default mode Bash parses it as uname with a redirection. This may be the only situation where Posix mode differs from default mode in *lexing*. And at least in my antique version, the --posix switch doesn't make that change. Dale
Re: `&>' doesn't behave as expected in POSIX mode
On Sun, Jun 20, 2021 at 10:18:59AM -0400, Eli Schwartz wrote:
>
> *Neither* behavior is similar to e.g. dash's behavior, or for that
> matter ksh. Both print the uname output after registering it as a
> backgrounded job (redirection does not get applied to the command itself).
Quick comparission script (note my default bash version in 5.0.3(1) and my
current working directory is my last bash-5.1.8 built):
$ echo $BASH_VERSION $PWD
5.0.3(1)-release /tmp/bash/bash-5.1.8
$ for KindOfShell in csh ksh dash 'busybox sh' {,./}'bash --posix' ; do
printf "\n#< %s >#\n" ${KindOfShell%% *}
LANG=C $KindOfShell -xc 'uname &>/dev/null ls -ld /t{mp,nt}'
done
#< csh >#
[1] 587
uname
Linux
ls -ld /tmp /tnt
ls: cannot access '/tnt': No such file or directory
[1] + Done uname
#< ksh >#
+ ls -ld /tmp /tnt
+ 1> /dev/null
+ uname
Linux
ls: cannot access '/tnt': No such file or directory
#< dash >#
+ ls -ld /t{mp,nt}
+ uname
Linux
ls: cannot access '/t{mp,nt}': No such file or directory
#< busybox >#
+ uname ls -ld '/t{mp,nt}'
#< bash >#
+ uname ls -ld /tmp /tnt
#< ./bash >#
+ uname ls -ld /tmp /tnt
There is some *different* behaviours... (but against `/t{mp,nt}` too!)
--
Félix Hauri -- http://www.f-hauri.ch
