set +o posix disables allowing tab as input
I have my tab key set to generate a tab key instead of doing auto complete and use ` for auto complete -- not ideal, but it works. I found a bug in this today. GNU bash, version 4.2.45(1)-release (x86_64-suse-linux-gnu) if I type in "set +o posix" to make sure posix mode is 'off', then 'tab' is no longer allowed as input. Ideas?
Some kind of file descriptor overflow
The script is in the answer: http://stackoverflow.com/questions/24192459/bash-running-out-of-file-descriptors It has 3 global variables, finishing in _CP, _TB and _CO. It runs out of file descriptors after 1 or 2 hours. I do not know much about Linux but I hope it helps you. GNU bash, version 4.2.37(1)-release (i486-pc-linux-gnu) -- Atte.: Jorge Sivil
Re: Some kind of file descriptor overflow
On Fri, Jun 13, 2014 at 09:52:49AM -0300, Jorge Sivil wrote: > The script is in the answer: > > http://stackoverflow.com/questions/24192459/bash-running-out-of-file-descriptors Can't you reduce the script to a minimum reproducible case? To be honest, it smells like a scripting error and not a bug, but the code in that answer is too large and with too many dependencies to be even worth the time to execute.
Re: Some kind of file descriptor overflow
Yes, sorry. The minimum reproduceable code is:
#!/bin/bash
function something() {
while true
do
while read VAR
do
dummyvar="a"
done < <(find "/run/shm/debora" -type f | sort)
sleep 3
done
}
something &
Which fails with many pipes fd open.
Changing the While feed to this:
#!/bin/bash
function something() {
find "/run/shm/debora" -type f | sort | while true
do
while read VAR
do
dummyvar="a"
done
sleep 3
done
}
something &
Works completely normal.
However, removing the call as function in background:
#!/bin/bash
while true
do
while read VAR
do
dummyvar="a"
done < <(find "/run/shm/debora" -type f | sort)
sleep 3
done
But executing the script with ./test.sh & (in background), works
without problems too.
On Fri, Jun 13, 2014 at 2:35 PM, Eduardo A. Bustamante López
wrote:
> On Fri, Jun 13, 2014 at 09:52:49AM -0300, Jorge Sivil wrote:
>> The script is in the answer:
>>
>> http://stackoverflow.com/questions/24192459/bash-running-out-of-file-descriptors
> Can't you reduce the script to a minimum reproducible case? To be
> honest, it smells like a scripting error and not a bug, but the code
> in that answer is too large and with too many dependencies to be even
> worth the time to execute.
--
Atte.: Jorge Sivil
unhelpful effect of '!' prefix on commands in conditionals - a bug ?
Having defined a function _F to return a non-zero return status :
$ function _F () { return 255; }
I'd expect to be able to test this return status in an if clause - but
this is what happens:
$ if ! _F ; then echo '_F returned: '$?; fi
_F returned: 0
whereas if I just run F inline, the return status is available:
$ _F; echo $?
255
Interestingly, if I don't use '!' in the conditional, I can access the
the return status:
$ if _F ; then echo OK; else echo '_F returned: '$?; fi
_F returned: 255
This is with bash:
$ bash --version
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
...
from an up-to-date copy of "Scientific Linux release 6.5" for X86_64 .
This behavior seems to me to be an instant source of confusion and bugs -
does anyone agree with me that this is a bug ?
Is this really mandated by the standards ?
Is there some other variable I could test to retrieve $? if it has
been mangled by a '!'
in the conditional ?
Is there any other conclusion than : "if you want to access the return
status of a
function in an if clause , don't use '!' in the conditional" ?
Any responses / suggestions gratefully received.
Thanks & Regards,
Jason
Re: unhelpful effect of '!' prefix on commands in conditionals - a bug ?
On 06/13/2014 02:42 PM, Jason Vas Dias wrote:
> Having defined a function _F to return a non-zero return status :
> $ function _F () { return 255; }
> I'd expect to be able to test this return status in an if clause - but
> this is what happens:
> $ if ! _F ; then echo '_F returned: '$?; fi
> _F returned: 0
This behavior is required by POSIX. The exit status of ! is either 0 or
1, depending on whether the exit status of the command it wrapped was
non-zero or zero.
> This behavior seems to me to be an instant source of confusion and bugs -
> does anyone agree with me that this is a bug ?
The only confusion here is that you are unaware that ! affects $?. Since
the behavior is standardized by POSIX and consistent with all other
shells, there is nothing to change in bash.
>
> Is this really mandated by the standards ?
Yes. Quoting POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_02
If the pipeline does not begin with the ! reserved word, the exit status
shall be the exit status of the last command specified in the pipeline.
Otherwise, the exit status shall be the logical NOT of the exit status
of the last command. That is, if the last command returns zero, the exit
status shall be 1; if the last command returns greater than zero, the
exit status shall be zero.
>
> Is there some other variable I could test to retrieve $? if it has
> been mangled by a '!'
> in the conditional ?
Don't use ! in the conditional. Take time to grab the status yourself.
$ if _F ; then :; else echo '_F returned: '$?; fi
>
> Is there any other conclusion than : "if you want to access the return
> status of a
> function in an if clause , don't use '!' in the conditional" ?
Not just functions, but ANY command.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Some kind of file descriptor overflow
On Fri, Jun 13, 2014 at 9:56 PM, Jorge Sivil wrote:
> Yes, sorry. The minimum reproduceable code is:
>
> #!/bin/bash
> function something() {
> while true
> do
> while read VAR
> do
> dummyvar="a"
> done < <(find "/run/shm/debora" -type f | sort)
> sleep 3
> done
> }
> something &
>
> Which fails with many pipes fd open.
>
> Changing the While feed to this:
>
> #!/bin/bash
> function something() {
> find "/run/shm/debora" -type f | sort | while true
> do
> while read VAR
> do
> dummyvar="a"
> done
> sleep 3
> done
> }
> something &
>
> Works completely normal.
>
> However, removing the call as function in background:
>
> #!/bin/bash
> while true
> do
> while read VAR
> do
> dummyvar="a"
> done < <(find "/run/shm/debora" -type f | sort)
> sleep 3
> done
>
> But executing the script with ./test.sh & (in background), works
> without problems too.
>
> On Fri, Jun 13, 2014 at 2:35 PM, Eduardo A. Bustamante López
> wrote:
> > On Fri, Jun 13, 2014 at 09:52:49AM -0300, Jorge Sivil wrote:
> >> The script is in the answer:
> >>
> >>
> http://stackoverflow.com/questions/24192459/bash-running-out-of-file-descriptors
> > Can't you reduce the script to a minimum reproducible case? To be
> > honest, it smells like a scripting error and not a bug, but the code
> > in that answer is too large and with too many dependencies to be even
> > worth the time to execute.
>
>
>
> --
> Atte.: Jorge Sivil
>
> yes, there was a bug and it has been fixed in 4.3 as far as i can tell
