Re: bash leaks sh-np-NNN files and pipes in /tmp/ when command substitution is used
On 12/11/2013 22:53, Piotr Grzybowski wrote:
Yuri: I have verified that under linux 3.2.0, bash-4.2.25, nothing of
the sort takes place. tee gets/dev/fd/${somefd}, why it is not
supported in bsd kernel i have no idea, but I thought it was. I've
even built mplayer and run your script (btw. probably there is an
easier way of doing what you want), I also performed some tests with
command that actually outputs what grep looks for. Also please note
that `command substitution`, or $(command substitution) is slightly
different from >(process substitution).
Piotr,
/dev/fd/{somefd} is quite an advanced feature, and it can be/has been
argued that it can lead to unpredictable behavior when file descriptors
appear/disappear. So FreeBSD only implements fds 0,1,2. Even those can
be closed too.
There are some other systems without such feature, and bash should be
fixed to work fine without it.
Yuri
Re: bash leaks sh-np-NNN files and pipes in /tmp/ when command substitution is used
well, no argue there, I just wanted to point out that where /dev/fd/
is available this issue is noexistent.
if i find the bsd system i have access to, i can investigate further.
cheers,
pg
On Thu, Dec 12, 2013 at 10:41 AM, Yuri wrote:
> On 12/11/2013 22:53, Piotr Grzybowski wrote:
>
> Yuri: I have verified that under linux 3.2.0, bash-4.2.25, nothing of
> the sort takes place. tee gets /dev/fd/${somefd}, why it is not
> supported in bsd kernel i have no idea, but I thought it was. I've
> even built mplayer and run your script (btw. probably there is an
> easier way of doing what you want), I also performed some tests with
> command that actually outputs what grep looks for. Also please note
> that `command substitution`, or $(command substitution) is slightly
> different from >(process substitution).
>
>
> Piotr,
>
> /dev/fd/{somefd} is quite an advanced feature, and it can be/has been argued
> that it can lead to unpredictable behavior when file descriptors
> appear/disappear. So FreeBSD only implements fds 0,1,2. Even those can be
> closed too.
> There are some other systems without such feature, and bash should be fixed
> to work fine without it.
>
> Yuri
Re: bash leaks sh-np-NNN files and pipes in /tmp/ when command substitution is used
On Thu, Dec 12, 2013 at 07:53:32AM +0100, Piotr Grzybowski wrote:
> Yuri: I have verified that under linux 3.2.0, bash-4.2.25, nothing of
> the sort takes place. tee gets /dev/fd/${somefd}, why it is not
> supported in bsd kernel i have no idea, but I thought it was.
On OpenBSD, at least, this is true. I haven't tried FreeBSD.
If bash is using named pipes of the form /var/tmp/sh-np-* or /tmp/sh-np-*
then the compile-time options or detection must have failed to find a
usable /dev/fd/ subsystem. (My HP-UX workstation is littered with
sh-np-* FIFOs in BOTH /tmp and /var/tmp.)
read builtin is not honoring -t argument
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-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic uname output: Linux tibs6 3.11.10-200.fc19.x86_64 #1 SMP Mon Dec 2 20:28:03 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.2 Patch Level: 45 Release Status: release Description: read builtin is not honoring -t argument Repeat-By: Just run 'read -t1' and note that the behavior seems not different from simply running 'read' without arguments.
Re: read builtin is not honoring -t argument
On Tue, Dec 10, 2013 at 11:28:31PM -0800, toddbst...@gmail.com wrote: > Machine Type: x86_64-redhat-linux-gnu > > Bash Version: 4.2 > Patch Level: 45 > Just run 'read -t1' and note that the behavior seems not different from > simply running 'read' without arguments. I can't duplicate this with Debian's 4.2.37. 'read -t1' times out after 1 second, while 'read' with no arguments waits for terminal input.
Re: bash leaks sh-np-NNN files and pipes in /tmp/ when command substitution is used
On 12/12/13 8:02 AM, Greg Wooledge wrote:
> On Thu, Dec 12, 2013 at 07:53:32AM +0100, Piotr Grzybowski wrote:
>> Yuri: I have verified that under linux 3.2.0, bash-4.2.25, nothing of
>> the sort takes place. tee gets /dev/fd/${somefd}, why it is not
>> supported in bsd kernel i have no idea, but I thought it was.
>
> On OpenBSD, at least, this is true. I haven't tried FreeBSD.
Unless things have gotten better on FreeBSD, it isn't. The issue with
FreeBSD is that is has historically only provided /dev/fd/[012], and
that isn't general enough for bash's use. FIFOs are definitely a
second choice here.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: read builtin is not honoring -t argument
On 12/11/13 2:28 AM, toddbst...@gmail.com wrote: > Bash Version: 4.2 > Patch Level: 45 > Release Status: release > > Description: > read builtin is not honoring -t argument > > Repeat-By: > Just run 'read -t1' and note that the behavior seems not different from > simply running 'read' without arguments. I can't reproduce this anywhere. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: read builtin is not honoring -t argument
2013/12/11 > > Description: > read builtin is not honoring -t argument > > Repeat-By: > Just run 'read -t1' and note that the behavior seems not different > from simply running 'read' without arguments. > What does ''type read'' say? perhaps you have a function or alias by that name. I can't reproduce it either. -- Geir Hauge
Re: read builtin is not honoring -t argument
I'm very sorry; I believe I may have wasted your time. After further testing, I can only reproduce this using xfce4-terminal (0.6.2) in Fedora 19. Read works fine in gnome-terminal and on tty's, so I hereby respectfully retract my report. Thank you for the work you guys do! Just to show I'm not (completely) insane, though: [todd@tibs6 ~]$ echo $0 bash [todd@tibs6 ~]$ type -a read read is a shell builtin read is /usr/bin/read read is /bin/read [todd@tibs6 ~]$ time timeout -s 9 5s read -t 1 Killed real0m5.001s user0m0.000s sys0m0.000s [todd@tibs6 ~]$ time read -t 1 asdf real0m7.904s user0m0.000s sys0m0.000s --- On Thu, Dec 12, 2013 at 7:49 AM, Geir Hauge wrote: > 2013/12/11 > >> Description: >> read builtin is not honoring -t argument >> >> Repeat-By: >> Just run 'read -t1' and note that the behavior seems not >> different from simply running 'read' without arguments. >> > > What does ''type read'' say? perhaps you have a function or alias by that > name. I can't reproduce it either. > > -- > Geir Hauge >
Re: bash leaks sh-np-NNN files and pipes in /tmp/ when command substitution is used
On 12/12/2013 05:02, Greg Wooledge wrote:
If bash is using named pipes of the form /var/tmp/sh-np-* or /tmp/sh-np-*
then the compile-time options or detection must have failed to find a
usable/dev/fd/ subsystem. (My HP-UX workstation is littered with
sh-np-* FIFOs in BOTH /tmp and /var/tmp.)
BSDs traditionally opposed to /dev/fd and /proc file systems. bash
configure specifically tests for /dev/fd/3 and notes this is to detect
FreeBSD, which only implements /dev/fd/{0..2}.
I also have a lot of /tmp/sh-np-*. bash leaves them when race condition
doesn't occur. And when it occurs, oddly, this is because the premature
deletion of /tmp/sh-np-*
If they would keep those fifos in deleted state as much of the time as
possible, such leak would be minimal.
Yuri
bug-bash@gnu.org
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../bash -I../bash/include -I../bash/lib
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -Wall
uname output: Linux treehug.home.kurahaupo.gen.nz 3.2.0-54-generic
#82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.2
Patch Level: 25
Release Status: release
Description:
The value of $? after starting a backgrounded command is
inconsistent:
$? is unchanged after starting a sufficiently complex command, but
after starting a simpler command it is set to 0.
Determining "sufficiently complex" has been a bit tricky, but it
appears to depend only on the type of the top-level node of the
parse-tree:
An unbracketed conditional chain of pipelines will leave $? set to 0
regardless of the complexity of its components. Likewise invoking a
function will leave $? set to 0 no matter how complex the body of
the function may be.
Conversely, grouping even a single simple command with brackets or
using any control structure will leave $? untouched.
Repeat-By:
( (exit 42) ; :& echo $? ; wait ) # says 0
( (exit 42) ; : | : && : || : & echo $? ; wait ) # says 0
( (exit 42) ; : | if :; then :; fi & echo $? ; wait ) # says 0
( (exit 42) ; if :; then :; fi & echo $? ; wait ) # says 42
( (exit 42) ; { : ; } & echo $? ; wait ) # says 42
