Re: set isearch-terminators "\r" in .inputrc causes malloc assert fails/death
On 5 May 2016, at 13:48, Eduardo A. Bustamante López wrote: > I'm able to replicate with the master branch. [..] yes, it appeared on the master with: commit ac50fbac377e32b98d2de396f016ea81e8ee9961 Date: Wed Feb 26 09:36:43 2014 -0500 Bash-4.3 distribution sources and documentation at the following it is still fine: commit 4539d736f1aff232857a854fd2a68df0c98d9f34 Date: Tue Feb 25 20:36:50 2014 -0500 prep for bash-4.3 release at the same time on bash-4.3-testing right to the end it is fine, including: commit b6e23235f28b1c85e18e9a2b7ba8c6b6c46aecbc Date: Wed Jan 29 17:00:07 2014 -0500 bash-4.3-rc2 overlay so I guess that diff b6e23235f28b1c85e18e9a2b7ba8c6b6c46aecbc ac50fbac377e32b98d2de396f016ea81e8ee9961 holds the key to this secret. At the current devel it is not present. Also, for those who would like to reproduce it, I was only able to do it with unset HISTCONTROL, and also for some reasons only under login shell (i.e. after actual chsh). cheers, pg
Re: namref dicussion continued: [PATCH] export -r reference
On 5/5/16 6:02 PM, Dan Douglas wrote: > On Thu, May 5, 2016 at 2:46 AM, Piotr Grzybowski wrote: >> ok, so Dan wants this patch. > > Yes I think your bash patch is probably an improvement at least in > this particular case. > >> Maybe you can comment on wether the patches are valid. > > The posix export and readonly don't produce locally scoped variables > at all, so it's expected that e.g. `typeset -x` and `export` will > differ. This is a different topic entirely, since neither of the examples we're considering take place within a function. Scoping isn't an issue. -- ``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: namref dicussion continued: [PATCH] export -r reference
On 5/4/16 12:30 PM, Piotr Grzybowski wrote:
> Hey,
>
> after another discussion with Grisha, and following one of his remarks, I
> kindly request your opinion on the attached patch (like: bad, not needed,
> already done, weak as it stands, harmful, etc.). It addresses the exporting
> of identifiers with have nameref attribute set.
> at the moment we have:
>
> #a=10; declare -nx ra=a; bash -c 'echo "a:$a, ra:$ra, ra_excl:${!ra}."'
> a:, ra:a, ra_excl:.
> #a=10; declare -n ra=a; export ra; bash -c 'echo "a:$a, ra:$ra,
> ra_excl:${!ra}."'
> a:10, ra:a, ra_excl:10
I'm not going to add another option to export before bash-4.4 is released.
This discussion, as useful as it's been, has already delayed the release
too long.
The above behavior is a pretty straightforward application of the nameref
rules: in the first case, ra is assigned `a' but never dereferenced; in
the second case, `ra' is dereferenced when used as the argument to
`export'. `unset' works the same way. bash and ksh93 work the same with
the second case, though ksh93, for some reason, doesn't allow -nx in any
combination as options to typeset.
--
``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: set isearch-terminators "\r" in .inputrc causes malloc assert fails/death
On 5/4/16 1:43 PM, Britton Kerin wrote: > I tried with export INPUTRC=test_inputrc, where test_inputrc contains > just this: > > set isearch-terminators "\r" > > this causes bash to sometimes spit out things like this: I can't reproduce this with bash-4.3.42 on RHEL 7, and there's independent confirmation that it's not reproducible in the latest devel version. I'm going to call it fixed in bash-4.4. 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: History modifier :p ignored prior to another history reference
On 5/3/16 12:15 PM, Dean Stanton wrote: > History modifier :p is not honored when it appears prior to another history > reference on the same command line. csh and tcsh appear to make the :p modifier apply to every history expansion on the line if it appears anywhere in the line. I'll take a look and see about whether I can make that change before bash-4.4 is released. It seems safer to honor :p everywhere than to execute a command where it's unintended. 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: History modifier :p ignored prior to another history reference
On 5/5/16 2:08 PM, Piotr Grzybowski wrote: > Hey, > > confirmed, this is what happens by construction. > this one is going to be tricky, expansion happens on the shell line, way > before it comes to execution. I do not see reparsing again at execute_command > even if we had means, which we dont, to store the information from history > expansion to know what to execute and what not. Re-tokenizing by rules of > history expansion anywhere outside histexpand seems out of place as much as > implementing shell lexer (again) in histexpand. Maybe splitting in > history_expand and returning tokens with options, that are later put together > for execution? Either way seems a bit large. > Currently the design indicates: :p applies to the whole line. Yes, the behavior as inherited from csh and tcsh should be that :p in any history expansion on the line will apply to the entire line. It's an easy one-character fix. -- ``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: IFS as the control variable in a for loop
On 5/2/16 3:06 PM, Grisha Levit wrote: > When in a non-interactive shell, IFS, when modified as the control variable > in a for loop does not change splitting behavior. > $ bash -c 'for IFS in .; do printf "%s\n" "$IFS" "$*"; done' bash x x > . > x x > > $ bash -ic 'for IFS in .; do printf "%s\n" "$IFS" "$*"; done' bash x x > . > x.x Thanks for the report; this is an easy fix. The fix will be in bash-4.4. 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: namref dicussion continued: [PATCH] export -r reference
On Sun, May 8, 2016 at 6:03 PM, Chet Ramey wrote: > On 5/5/16 6:02 PM, Dan Douglas wrote: >> On Thu, May 5, 2016 at 2:46 AM, Piotr Grzybowski wrote: >>> ok, so Dan wants this patch. >> >> Yes I think your bash patch is probably an improvement at least in >> this particular case. >> >>> Maybe you can comment on wether the patches are valid. >> >> The posix export and readonly don't produce locally scoped variables >> at all, so it's expected that e.g. `typeset -x` and `export` will >> differ. > > This is a different topic entirely, since neither of the examples > we're considering take place within a function. Scoping isn't an > issue. Sure I agree that scope isn't the issue. That's was the main point of my message. I was trying to explain is that ksh does allow -x in combination with pre-existing references in some contexts, but the only way to demonstrate that is by calling a function.
