Re: Savannah and (getting old) issue 108530 reported there
On 6/2/15 5:24 AM, Balaco Baco wrote: I'm surprised to read you saying that this is not a problem with Bash. Because technically the history facilities are provided by readline, and bash builds on those. 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. It reads and writes history files, but the session history it keeps, and the history that, for instance, the `history' and `fc' commands act on, is a list kept in memory and managed by the history library that's part of readline. This is the way it has always been. You may not like that design. You may think it causes you problems. But it is the implementation. Bash has HIST_CONTROL, HISTFILESIZE and HISTSIZE (at least) to let us control how *files* are kept, including history files (not only memory commands). The only one of those that acts on a file is HISTFILESIZE. I think it's a problem with Bash and that it should be addressed by Bash, directly or not (since you point to Readline). Thank you. You have reported the issue. I have looked at it before, but I concluded that it was not the highest priority thing I could be spending my limited development time doing. You are free to, and I encourage you to, modify bash to use a file-based history mechanism and to implement some kind of synchronization between processes that use it. I would be glad to look at your work. If you want to take a shot at solving the general problem, great. If you don't want to, take a look at the hist_erasedups() function I referred to in my message. There's a little more bookkeeping you'd have to do if you put it into bash, but that should be straightforward. I'd appreciate the help, and you would solve your problem. 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, ... I changed the status to `postponed'. -- ``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: unset does not act as expected on namerefs
On Tue, Jun 2, 2015 at 7:31 AM, Greg Wooledge wool...@eeg.ccf.org wrote: There's declare -i, but no sane person USES that, so we can ignore it. While in bash `-i` likely either has no effect or slows things down very slightly, in ksh93 and probably zsh it's a huge performance win because it prevents integers and floats from being automatically coerced to and from a string on every operation. It also guarantees (after the attribute is set) that the value will never be anything other than the right type unless the attribute is explicitly removed. It's perfectly sane to use it for values that are always guaranteed correct by construction or by validation. (Use the `integer' and `float' aliases in ksh, which are preset to use the largest currently available type). So long as you always remember to initialize the variable you can't really go wrong with it.
Re: unset does not act as expected on namerefs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/1/15 9:59 PM, Shawn Wilson wrote: Top posting as I'm kinda going out of band of the thread here; Having read the discussion, I guess the issue I brought up really isn't a bug (though Greg's points probably should be considered bugs). I'll preface this by saying I'm not an expert in bash by any means. However, most languages have a garbage collection facility which cleans up anonymous refs with nothing pointing to it and most high level languages make it easier to make a soft or symbolic reference than making hard references. But also, when you 'undef'/delete()/whatever the variable or the pointer, handle both and avoid this issue. While I do like the idea of pointers for bash variables, I would much prefer being able to create references. 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() ). I think it's a case of mismatched expectations. There are a couple of ways to go with this, and I went with the way Korn specified `unset'. I initially implemented namerefs in bash without any special changes to unset, but ended up adding it for compatibility. Bash's dynamic scoping also drove some of the decisions. Just as you can follow the call chain to get different instances of a variable named `x', for example, you get the same kind of variable resolution with namerefs when you use `soft' symbolic references rather than `hard' pointer references. You absolutely have to be careful when you do this; this part of the shell is a sharp instrument. It's like I told Greg: dynamic scoping is fundamental to how bash works, and namerefs don't change that. (Bash-4.3 has a way to test whether or not a variable is a nameref: `test -R'.) There's no need to flame anyone about this. It's fair to discuss the rationale for design decisions. 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/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlVzIgoACgkQu1hp8GTqdKufHQCeL4Z0v8l9Au7hWJbr/lnT3NxI SOsAn1gDxHDXkshb8mfRaANy8dFyhOlh =bZx+ -END PGP SIGNATURE-
Re: unset does not act as expected on namerefs
On 6/2/15 11:37 AM, Greg Wooledge wrote: 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. In my opinion, the most interesting thing about ksh93's namerefs is that they change ksh to allow dynamic scoping and give funtions access to a calling function's local variables. ksh93 doesn't normally allow that, and David Korn was very vocal about the superiority of ksh93's static scoping. -- ``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: Bug, feature or just the correct behaviour (stat'ing -bash down the PATH)
On 6/2/15 9:08 AM, Wheatley, Martin R wrote: $ 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. This does look like bash is setting the BASH variable, which is the full pathname, as best as bash can figure, to the current instance of bash. It's not always $SHELL, for obvious reasons, and not $0. This question used to come up a lot. The puzzling thing is the `-bash'. Current versions of bash don't add the `-' at the beginning of the shell name, and I'm not sure older versions did, either. You look like you're using Solaris, though, so ancient versions are definitely possible. 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. You can't mount -o intr? 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/
