Bug in bash 4.3.30 with --disable-job-control
All,
There is a bug of some sort in bash 4.3.30 (and likely others) when
compiled with --disable-job-control on Linux/x86_64.
The following script will produce output after running for about 30 seconds:
while true; do dfOutput="$(/bin/echo test)"; if echo "${dfOutput}" |
/bin/false; then echo Impossible; fi; done
It should never produce any output, and will not produce any output if
bash is compiled with --enable-job-control.
Additionally, the commands may be run out of order when they involve a pipe.
For example:
while true; do dfOutput="$(/bin/echo test)"; if echo "${dfOutput}" |
/bin/false; then echo a; echo b | cat; echo c; echo ---; fi; done
Can produce the output:
a
c
---
b
a
...
I have done no further investigation.
Thanks,
Roy Keene
Re: unset does not act as expected on namerefs
On +2015/06/02 08:31:57, Greg Wooledge wrote: > > > Also, whatever happens, I think there should also be a way to test > > for variable type (either another test flag or something like perl's > > ref() ). > > Bash is not a strongly typed language. You've got strings, and indexed > arrays, and associative arrays. That's all. (There's declare -i, but > no sane person USES that, so we can ignore it.) > > You might be trying to do things that Bash is simply not designed to do. > It's a shell. I would argue that a nameref is a variable type. pgpmvsk0XMiMp.pgp Description: PGP signature
Bug, feature or just the correct behaviour (stat'ing -bash down the PATH)
$ echo $PATH
/usr/bin:/usr/sbin:/usr/dt/bin:/home/USER/bin
$
a truss of "bash -ls" shows it stat'ing '-bash' in each of the directories
in PATH...
11933: stat64("/usr/bin/-bash", 0xFFBFEBE8)Err#2 ENOENT
11933: stat64("/usr/sbin/-bash", 0xFFBFEBE8) Err#2 ENOENT
11933: stat64("/usr/dt/bin/-bash", 0xFFBFEBE8) Err#2 ENOENT
11933: stat64("/home/USER/bin/-bash", 0xFFBFEBE8) Err#2 ENOENT
Why does bash do all these 'stat()' system calls? We tried providing an
executable '-bash' at one of the locations but it didn't appear to have
any effect.
If one of the directories in the PATH is on an NFS server that is
'down' then bash hangs - which disables a shell which would otherwise
be usable.
+---+
| Martin Wheatley | Voice : +44-(0)1235-464784 |
| CODAS & IT Department | FAX: +44-(0)1235-464404 |
| Culham Centre for Fusion Energy | E-mail : martin.wheat...@ccfe.ac.uk |
| Culham Science Centre |-|
| Abingdon, Oxfordshire | |
| OX14 3DB| |
| United Kingdom | WWW.CCFE.AC.UK |
+---+
Re: unset does not act as expected on namerefs
On Tue, Jun 02, 2015 at 11:16:27AM -0400, Shawn Wilson wrote:
> I would argue that a nameref is a variable type.
I suppose you're right, insofar as it has its own special rules that
you have to know about.
A lot of people wanted declare -n to be more than it is. It's really
just syntactic sugar that doesn't actually let you do anything you
couldn't do already (with printf -v for assignment, and ${!foo} or eval
for reference). So, like declare -i, it's something you can completely
disregard if you're writing new scripts, and not maintaining other
people's scripts.
Ksh's nameref is completely different. With one of ksh's two different
kinds of functions, you actually CAN use ksh nameref to pass a value
back to the caller without variable name collisions.
$ bash -c 'f() { local x=from_f; g x; }; g() { declare -n x="$1"; echo "$x"; };
f'
bash: warning: x: circular name reference
$ ksh -c 'f() { typeset x=from_f; g x; }; g() { typeset -n x="$1"; echo "$x";
}; f'
ksh: typeset: x: invalid self reference
$ ksh -c 'function f { typeset x=from_f; g x; }; function g { typeset -n
x="$1"; echo "$x"; }; f'
from_f
VPATH build failure on cygwin
Cygwin recently upgraded to GNU make 4.1, but in the process, it introduced a regression in behavior on how VPATH behaves [1]. In particular, the expression VPATH = .:/path/to/dir is no longer treated as a two-directory designation (search ., and if not found then search /path/to/dir) but as a one-directory designation as if . were a drive letter (but there is no '.' drive, so it results in no VPATH at all). I'm hoping to get this bug fixed (either in upstream make or in the cygwin port of make). But in the meantime, read what 'info make' says about VPATH: >Thus, if a file that is listed as a target or prerequisite does not > exist in the current directory, `make' searches the directories listed > in `VPATH' for a file with that name. That is, the use of .: in VPATH is redundant, and will NOT find any files that were not already found if you had omitted it, because make already searches the current directory before resorting to VPATH. Thus, in all of your Makefile.in files, you should change: VPATH = .:@srcdir@ to be: VPATH = @srcdir@ so that bash can once again be built with the current cygwin build of make; such a change will not break any other platforms. [1] https://cygwin.com/ml/cygwin/2015-06/msg00036.html -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: unset does not act as expected on namerefs
On Mon, Jun 01, 2015 at 09:59:51PM -0400, Shawn Wilson wrote: > I'll preface this by saying I'm not an expert in bash by any > means. However, most languages have a garbage collection facility C does not. Bash (all shells, really) is very strongly influenced by C. > and most > high level languages make it easier to make a soft or symbolic > reference than making hard references. Bash is not a high-level language. > Also, whatever happens, I think there should also be a way to test > for variable type (either another test flag or something like perl's > ref() ). Bash is not a strongly typed language. You've got strings, and indexed arrays, and associative arrays. That's all. (There's declare -i, but no sane person USES that, so we can ignore it.) You might be trying to do things that Bash is simply not designed to do. It's a shell.
Re: Savannah and (getting old) issue 108530 reported there
I'm surprised to read you saying that this is not a problem with Bash. I use Bash as my shell. As configure it (from its appropriate config file). And I get results opposite to what would be expected. And you say there is no problem with bash? Bash does not only deal with in memory lists because it reads the history from the file .bash_history when we open a new session. It will read history files with duplicate commands it wrote before, although we configured for not doing this. Bash has HIST_CONTROL, HISTFILESIZE and HISTSIZE (at least) to let us control how *files* are kept, including history files (not only memory commands). I think it's a problem with Bash and that it should be addressed by Bash, directly or not (since you point to Readline). And keeping an open and apparently unseen issue in Savannah is bad. Even if the decision would be what you said in this message, the assumed improvement I had (and have seen in others) before posting it there would not feel abandoned. Well, ... -- Balaco On Fri, May 15, 2015, at 12:18, Chet Ramey wrote: > On 5/15/15 8:44 AM, Balaco Baco wrote: > > I have this issue, and talking with several people and searching around, > > I see that this seems to be a recurring problem for many users. > > > > Some just "fix" it around by using a N times bigger history than they > > wished. Others just consider it a "bug that exists, but won't do nothing > > about it". > > This isn't a bug. Readline (and bash) only deals with in-memory history > lists -- the history facilities are not intended to, nor do they, > operate on disk files other than reading and writing them. There are > also no facilities for sharing history files between sessions other > than synchronizing the history file after each command. > > If you want to remove duplicates from a history file, you have to read > it into memory, use the existing history functions to operate on it, > and write it. There is a program (hist_erasedups.c) in the readline-6.3 > examples subdirectory that shows how to do that. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer >``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ -- http://www.fastmail.com - Does exactly what it says on the tin
