Re: Assignment-like word shouldn't be subjected to tilde expansion in POSIX mode
On 7/19/20 1:47 AM, Oğuz wrote:
> By the way,
> wouldn't it be better if the same tilde expansion rules as with assignment
> statements was applied to parameter expansions that assign default values?
> Like,
>
> unset foo
> echo ${foo=~:~otheruser}
>
> assigns `/home/oguz:~otheruser' to `foo' regardless of whether `otheruser'
> is a valid login name for an existing user.
Maybe, but Posix says this isn't a variable assignment context, as POSIX
defines variable assignments, and technically the shell shouldn't perform
tilde expansions after `=' or `:' at all. You could argue that bash has a
bug here in that it expands the tilde after the `='.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
'foo > >(bar)' doesn't set $! for external foo not invoked via 'command'
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wno-parentheses -Wno-format-security
uname output: Linux [...] 4.19.132-1.pvops.qubes.x86_64 #1 SMP Tue Jul 14
03:42:21 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 5.0
Patch Level: 17
Release Status: release
Description:
$! isn't set to the PID of 'bar' for
foo > >(bar)
if 'foo' is an external program (as opposed to a builtin or
function) - unless it's invoked via 'command'.
Repeat-By:
type date # "date is /usr/bin/date"
set -u
echo $! # "bash: $!: unbound variable"
date > >(sleep 20)
echo $! # "bash: $!: unbound variable"
command date > >(sleep 21)
echo $! # "123"
date_wrapper() { date; }
date_wrapper > >(sleep 22)
echo $! # "234"
For context - I'm filtering a program's stdout and stderr
(separately), requiring successful exit statuses for the program and
both filters:
set -u -o pipefail
{ program 2> >(stderr_filter >&2) && wait $!; } | stdout_filter && ...
This only works if 'program' is changed to 'command program'.
Rusty
signature.asc
Description: PGP signature
Re: 'foo > >(bar)' doesn't set $! for external foo not invoked via 'command'
19 Temmuz 2020 Pazar tarihinde Rusty Bird yazdı:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
> -fstack-protector-strong -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -Wno-parentheses -Wno-format-security
> uname output: Linux [...] 4.19.132-1.pvops.qubes.x86_64 #1 SMP Tue Jul 14
> 03:42:21 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-redhat-linux-gnu
>
> Bash Version: 5.0
> Patch Level: 17
> Release Status: release
>
> Description:
> $! isn't set to the PID of 'bar' for
>
> foo > >(bar)
>
> if 'foo' is an external program (as opposed to a builtin or
> function) - unless it's invoked via 'command'.
>
> Repeat-By:
> type date # "date is /usr/bin/date"
> set -u
> echo $! # "bash: $!: unbound variable"
>
> date > >(sleep 20)
> echo $! # "bash: $!: unbound variable"
>
> command date > >(sleep 21)
> echo $! # "123"
>
> date_wrapper() { date; }
> date_wrapper > >(sleep 22)
> echo $! # "234"
>
>
> For context - I'm filtering a program's stdout and stderr
> (separately), requiring successful exit statuses for the program and
> both filters:
>
> set -u -o pipefail
> { program 2> >(stderr_filter >&2) && wait $!; } | stdout_filter &&
> ...
>
Not sure if process substitution is really necessary here,
set -u -o pipefail
{ program 2>&3 | stdout_filter; } 3>&1 | stderr_filter && ...
does the same thing.
> This only works if 'program' is changed to 'command program'.
>
> Rusty
>
--
Oğuz
Re: Assignment-like word shouldn't be subjected to tilde expansion in POSIX mode
19 Temmuz 2020 Pazar tarihinde Chet Ramey yazdı:
> On 7/19/20 1:47 AM, Oğuz wrote:
> > By the way,
> > wouldn't it be better if the same tilde expansion rules as with
> assignment
> > statements was applied to parameter expansions that assign default
> values?
> > Like,
> >
> > unset foo
> > echo ${foo=~:~otheruser}
> >
> > assigns `/home/oguz:~otheruser' to `foo' regardless of whether
> `otheruser'
> > is a valid login name for an existing user.
>
> Maybe, but Posix says this isn't a variable assignment context, as POSIX
> defines variable assignments, and technically the shell shouldn't perform
> tilde expansions after `=' or `:' at all. You could argue that bash has a
> bug here in that it expands the tilde after the `='.
>
>
Yes, apparently that's a bug too, which in my opinion needs to be fixed in
normal mode as well.
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>
--
Oğuz
RE: Issue with Bash
Hi All, From what we have found out, it does not seem like the signal is SIGTTOU. We are working to find out more about it. Meanwhile, any insight would be helpful. Thanks and Regards, Rishita Saha - Original message - From: Chet Ramey To: "CHIGOT, CLEMENT" , Rishita Saha16 , "bug-bash@gnu.org" Cc: chet.ra...@case.edu Subject: [EXTERNAL] Re: Issue with Bash Date: Thu, Jul 9, 2020 8:01 PM On 7/9/20 10:16 AM, CHIGOT, CLEMENT wrote: > Hi Rishita, > > Could you try with BullFreeware's version, which have a slightly higher version (5.0.11 instead of 5.0) ? > You can find it at [1]http://www.bullfreeware.com/pkg?id=5740 <[2]http://www.bullfreeware. com/pkg?id=6102 >. > > If it's not working, I'll check what's wrong. It's not clear that any of those patches will affect this behavior. I'd be more interested in knowing the signal, and, if it's SIGTTOU, whether the process is an interactive shell. (Because if it's not, and I can't imagine that running httpd is going to start an interactive shell, why is it calling readline to get input?) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.edu [3]http://tiswww.cwru.edu/~chet/ References 1. http://www.bullfreeware.com/pkg?id=5740 2. http://www.bullfreeware.com/pkg?id=6102 3. http://tiswww.cwru.edu/~chet/
