Re: address XXX comment at lines 987-990 in bashfile.c
On Thu, Jul 09, 2015 at 01:53:52PM -0700, Bill Parker wrote: Hello All, In reviewing the code at line 990 in bashfile.c, while the issue of rl_line_buffer[0] = '\0', would it not be better to use memset(rl_line_buffer, '\0', sizeof(rl_line_buffer)) to clobber the entire line more effectively? The patch file below addresses this issue: [...] I don't think the intention of that line is to clear the whole buffer. If that buffer is to hold a C string, then the current code is sufficient to make that a 'null' string. -- Eduardo Bustamante https://dualbus.me/
${!prefix@} no longer expands in Bash 4.4-alpha
Bash 4.4-alpha no longer expands ${!prefix@}.
${!prefix*} however still works.
bash-4.4-alpha-4.4# var_1=a var_2=b
bash-4.4-alpha-4.4# set -- ${!var_@}
bash-4.4-alpha-4.4# echo $#
0
bash-4.4-alpha-4.4# set -- ${!var_@}
bash-4.4-alpha-4.4# echo $#
1
bash-4.4-alpha-4.4# set -- ${!var_*}
bash-4.4-alpha-4.4# echo $#
2
konsolebox
problem with HISTCONTROL
When the value of HISTCONTROL is ignoredups or ignoreboth, if you enter a command and then open the editor and add lines to it without changing the first line, only the first line will be stored in the history. I'm terrible at explaining, but I recorded what happens: https://asciinema.org/a/23275 Hopefully it's clear enough, I'm pressing up arrow to get that line. I tested a few versions and I can reproduce it in 3.1 and above. --- xoxo iza
Re: address XXX comment at lines 987-990 in bashfile.c
The comment above the line would seem to indicate otherwise: Here is the comment: /* Now erase the contents of the current line and undo the effects of the rl_accept_line() above. We don't even want to make the text we just executed available for undoing. */ Bill On Fri, Jul 10, 2015 at 11:30 PM, Eduardo A. Bustamante López dual...@gmail.com wrote: On Thu, Jul 09, 2015 at 01:53:52PM -0700, Bill Parker wrote: Hello All, In reviewing the code at line 990 in bashfile.c, while the issue of rl_line_buffer[0] = '\0', would it not be better to use memset(rl_line_buffer, '\0', sizeof(rl_line_buffer)) to clobber the entire line more effectively? The patch file below addresses this issue: [...] I don't think the intention of that line is to clear the whole buffer. If that buffer is to hold a C string, then the current code is sufficient to make that a 'null' string. -- Eduardo Bustamante https://dualbus.me/
Re: Troubles with autocompletion of filenames with square brackets
On 7/10/15 3:36 AM, deterenkelt.git...@gmail.com wrote: Bash Version: 4.3 Patch Level: 39 Release Status: release Description: Autocompletion fails for files starting with an opening square bracket and having closing bracket somewhere in the filename. I can't reproduce this using bash-4.3.39 on Mac OS X. Please type complete -r and try your examples again. If they work, you should file a bug report with your vendor against the bash-completion package. 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: Troubles with autocompletion of filenames with square brackets
Thanks, now the completion works fine, I’ll send a bug to maintainers. 2015-07-12 4:34 GMT+03:00 Chet Ramey chet.ra...@case.edu: On 7/10/15 3:36 AM, deterenkelt.git...@gmail.com wrote: Bash Version: 4.3 Patch Level: 39 Release Status: release Description: Autocompletion fails for files starting with an opening square bracket and having closing bracket somewhere in the filename. I can't reproduce this using bash-4.3.39 on Mac OS X. Please type complete -r and try your examples again. If they work, you should file a bug report with your vendor against the bash-completion package. Chet -- ``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/
Re: bash-4.3 stack smashing
On 7/9/15 5:44 AM, Ondrej Oprala wrote: Hi, devel branch's commit 67440b introduced a change in sig.c; specifically, deleting line 608 seems to solve the problem (though I've no idea what else it breaks). Thanks for the report and the pointer to the place to investigate. This will be fixed in the next test release, and in the next devel snapshot. 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: ${!prefix@} no longer expands in Bash 4.4-alpha
On 7/11/15 12:17 PM, konsolebox wrote:
Bash 4.4-alpha no longer expands ${!prefix@}.
${!prefix*} however still works.
Yeah, it was a bad idea to make ${!prefix@} ever work in the first place.
The original intent was to use ${!prefix*} like in ksh93, but * and @ are
the same just about everywhere else in word expansions. The exception is
the new set of ${param@op} expansions.
This will work again in the next test release.
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: address XXX comment at lines 987-990 in bashfile.c
On 7/11/15 4:15 PM, Bill Parker wrote: The comment above the line would seem to indicate otherwise: Here is the comment: /* Now erase the contents of the current line and undo the effects of the rl_accept_line() above. We don't even want to make the text we just executed available for undoing. */ Eduardo is correct. The valid portion of the readline line buffer is the string bounded by 0 and rl_end. rl_line_buffer[rl_end] == 0, and setting rl_line_buffer[rl_point = rl_end = 0] is sufficient to erase the contents of the line buffer. 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/
