Bad file descriptor with pipeline
Hi, If i use : `strace bash -c "echo qsd | cat" 2>&1 | grep "close"` I get systematically : close(3)= 0 close(3)= 0 close(3)= 0 close(3)= 0 close(3)= 0 close(3)= 0 close(3)= 0 close(3)= 0 close(4)= 0 close(4)= -1 EBADF (Bad file descriptor) close(3)= 0 close(3)= -1 EBADF (Bad file descriptor) I don't know if it's a bug or not. This error happens everytime a pipeline is used. GNU bash, version 4.3.42(1)-release (x86_64-unknown-linux-gnu) We discussed about it here : (french) zestedesavoir.com/forums/sujet/5779/bash-et-les-bugs/ Nheir sayed that he saw something in the file function execute_pipeline of the file execute_cmd.c
Pipeline close(4) Bad file descriptor
Hi, If i use : `strace bash -c "echo qsd | cat" 2>&1 | grep "close"` I get systematically : close(3)= 0 close(3)= 0 close(3)= 0 close(3)= 0 close(3)= 0 close(3)= 0 close(3)= 0 close(3)= 0 close(4)= 0 close(4)= -1 EBADF (Bad file descriptor) close(3)= 0 close(3)= -1 EBADF (Bad file descriptor) I don't know if it's a bug or not. This error happens everytime a pipeline is used. GNU bash, version 4.3.42(1)-release (x86_64-unknown-linux-gnu) We discussed about it here : (french)https://zestedesavoir.com/forums/sujet/5779/bash-et-les-bugs/ Nheir sayed that he saw something in the file function execute_pipeline of the file execute_cmd.c
Re: Bad file descriptor with pipeline
On 4/11/16 5:39 PM, Hédy GIRAUDEAU wrote: > Hi, > If i use : `strace bash -c "echo qsd | cat" 2>&1 | grep "close"` > I get systematically : > > close(3)= 0 > close(3)= 0 > close(3)= 0 > close(3)= 0 > close(3)= 0 > close(3)= 0 > close(3)= 0 > close(3)= 0 > close(4)= 0 > close(4)= -1 EBADF (Bad file descriptor) > close(3)= 0 > close(3)= -1 EBADF (Bad file descriptor) > > > I don't know if it's a bug or not. This error happens everytime a > pipeline is used. It's not a bug, it's bash making sure pipe file descriptors are closed. -- ``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: Bad file descriptor with pipeline
Le 12/04/2016 04:00, Chet Ramey a écrit : > On 4/11/16 5:39 PM, Hédy GIRAUDEAU wrote: >> Hi, >> If i use : `strace bash -c "echo qsd | cat" 2>&1 | grep "close"` >> I get systematically : >> >> close(3)= 0 >> close(3)= 0 >> close(3)= 0 >> close(3)= 0 >> close(3)= 0 >> close(3)= 0 >> close(3)= 0 >> close(3)= 0 >> close(4)= 0 >> close(4)= -1 EBADF (Bad file descriptor) >> close(3)= 0 >> close(3)= -1 EBADF (Bad file descriptor) >> >> >> I don't know if it's a bug or not. This error happens everytime a >> pipeline is used. > It's not a bug, it's bash making sure pipe file descriptors are closed. > Oh ok. That's a odd way to make sure that a file descriptor is closed but at least it works. Sorry for disturbing.
Filename completion broken for env variables
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-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic uname output: Linux psel702 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55 EST 2016 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.2 Patch Level: 46 Release Status: release Description: If my path contains an env variable, instead of expanding the variable as in pre 4.1 bash, it escapes it by prepending a backslash. After spending several hours searching the web for a fix, I find that this is considered a new feature as filename completion ideally shouldn't change what the user types. I suppose that would be a nice feature if it actually worked, but since the 4.2 implementation does change the user input by prepending a backslash and doesn't do the filename completion in some cases like cd commands, it's just wasting the time of everyone who uses tab completion w/ env variables and wants to figure out why after working for nearly 20 years it's now broken. Repeat-By: Here's an example. I want to run $FOO/testApp/my_test_application so I type % $FOO/testApp/my_test which is then replaced w/ % \$FOO/testApp/my_test_application which won't run due to the prepended backslash. Similarly, % ls $FOO/testApp/my_test produces % ls \$FOO/testApp/my_test_application while % cd $FOO/test doesn't work at all, leaving me w/ % cd $FOO/test Fix: Must set shopt direxpand, which since I work in an environment w/ a wide variety of RHEL5, RHEL6, and RHEL7 machines supported by our IT group means I either need to convince them to update all RHEL7 machines w/ a custom version of bash 4.3.30 or greater compiled w/ --enable-direxpand-default (nearly impossible in a big organization like ours) or add the following in my .bash_profile since direxpand isn't supported prior to bash 4.2. # Fix annoying feature in bash 4.2 that stops expanding env vars during file completion if ((BASH_VERSINFO[0] >= 5)) || ((BASH_VERSINFO[0] == 4)) && ((BASH_VERSINFO[1] >= 2)) then shopt -s direxpand fi It's really annoying to have to set a new option in order to disable a new feature that doesn't work properly. -- Bruce Hill Member Technical Staff SLAC National Accelerator Lab 2575 Sand Hill Road M/S 10 Menlo Park, CA 94025
