Re: test builtin does not check for nanoseconds while comparing timestamps
On 6/2/17 5:30 PM, Siteshwar Vashisht wrote: > Bash Version: 4.3 > Patch Level: 43 > Release Status: release > > Description: > If the modified timestamp of 2 files differ by less than 1 second, > test builtin sometimes returns incorrect result. It happens because > HAVE_STRUCT_STAT_ST_ATIM_TV_NSEC is not defined in config.h. Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Builtin read with -n0 or -N0 (nchars == 0) behaves as a read with no -n/-N argument
On 6/3/17 1:15 PM, Pranav Deshpande wrote: > Hello, > Sorry for the late reply. > > My solution is to change *line 294* of builtins/read.def. > > Change > if (code == 0 || *intval < 0* || intval != (int)intval) > > to > > if (code == 0 || i*ntval <= 0* || intval != (int)intval) That's a fine solution for behavior 1. If you'd prefer behavior 2, obviously you have to do something else. :-) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: minor: man-page: history file time comments for following not preceding history line
On 6/4/17 6:36 AM, Jörn Hees wrote: > Hi, > > in the HISTORY section of the man-page it says: > >> ... When the history file >> is read, lines beginning with the history comment character followed >> immediately by a digit are interpreted >> as timestamps for the preceding history line. > > s/preceding/following/ Thanks for the report. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Patch for unicode in varnames...
On Tue, 2017-06-06 at 10:20 -0400, Greg Wooledge wrote: > (OK, in reality, I am not taking any of this seriously. This entire > proposal and discussion are like some bizarre fantasy land to me. Bash > is a SHELL, for god's sake. Not a serious programming language. Even > serious programming languages are not ready for this; see the Python > proposal that was mentioned up-thread.) > I don't think "shell" and "serious programming language" must be considered mutually exclusive. Shell scripting is "serious" in the sense that there are people who rely upon and actively develop shell scripts to keep their products working. If the language itself seems not "serious" I think that is because not enough effort has been made to extend and improve its functionality over time. (At least, not in the Bash project... Korn Shell has done some good work along those lines.) But I think the "interactive" aspect is probably the most compelling argument for supporting something like this. The shell can serve as one of the primary tools for operating the computer. As such it should also aim to be a comfortable environment. If you tell a programmer that a shell only accepts ASCII in some contexts, there's a fair chance they'll understand why, and accept the limitation. For more casual users, this may not be the case. I think they'd be likely to wonder why they can't use accented characters, or other alphabets for parameter names. I don't think there's a particularly good reason not to allow it... Though I'd personally like to see it implemented in a way that allows scripts to take advantage of that, and still work reliably regardless of the locale setting in which they're ultimately run. As a side note, I had expressed concern that Bash might not work correctly with GB-18030 encoding, but it appears that I was wrong. I set up a terminal to display the GB-18030 character set, set the locale within the terminal to GB-18030, and formed a string that I would expect to expose a parser bug (a string of multi-byte Chinese characters including 0x7C, the byte that corresponds to the ASCII vertical bar character), but it appeared to parse the string correctly according to the locale rather than break it up on the 0x7C byte. So that's good. :)
Re: Patch for unicode in varnames...
Instead of talking in terms of seriousness, it may be more use to think in terms of formality. Even in gramitically strong and formal languages variable and function names are restricted in the characters they may use. This is not just because it makes the parsing simpler but because it simplifies reading comprehension of the code. Now bash is already very difficult for most to appreciate the subtitles of how it is written. Supporting an almost endless number of characters in car and fun names would just make it endlessly more complex to understand. This would be a bad idea in the same way that having control characters in filenames is a bad idea, just because you can do something doesn't mean you should. This is also a question of the tco (total cost of ownership) of code. The flexible you allow the coding to be the more difficult it is to understand others code. Perl(need to be a guru to read someone else's code) vs python(a noob can figure it out pretty quickly with Google.). On June 7, 2017 10:03:08 PM GMT+01:00, George wrote: >On Tue, 2017-06-06 at 10:20 -0400, Greg Wooledge wrote: >> (OK, in reality, I am not taking any of this seriously. This entire >> proposal and discussion are like some bizarre fantasy land to >me. Bash >> is a SHELL, for god's sake. Not a serious programming >language. Even >> serious programming languages are not ready for this; see the Python >> proposal that was mentioned up-thread.) >> >I don't think "shell" and "serious programming language" must be >considered mutually exclusive. >Shell scripting is "serious" in the sense that there are people who >rely upon and actively develop shell scripts to keep their products >working. If >the language itself seems not "serious" I think that is because not >enough effort has been made to extend and improve its functionality >over time. (At >least, not in the Bash project... Korn Shell has done some good work >along those lines.) >But I think the "interactive" aspect is probably the most compelling >argument for supporting something like this. The shell can serve as one >of the >primary tools for operating the computer. As such it should also aim to >be a comfortable environment. If you tell a programmer that a shell >only >accepts ASCII in some contexts, there's a fair chance they'll >understand why, and accept the limitation. For more casual users, this >may not be the >case. I think they'd be likely to wonder why they can't use accented >characters, or other alphabets for parameter names. I don't think >there's a >particularly good reason not to allow it... Though I'd personally like >to see it implemented in a way that allows scripts to take advantage of >that, >and still work reliably regardless of the locale setting in which >they're ultimately run. >As a side note, I had expressed concern that Bash might not work >correctly with GB-18030 encoding, but it appears that I was wrong. I >set up a >terminal to display the GB-18030 character set, set the locale within >the terminal to GB-18030, and formed a string that I would expect to >expose a >parser bug (a string of multi-byte Chinese characters including 0x7C, >the byte that corresponds to the ASCII vertical bar character), but it >appeared >to parse the string correctly according to the locale rather than break >it up on the 0x7C byte. So that's good. :) -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
Re: Patch for unicode in varnames...
On 08/06/2560 04:33, Dethrophes wrote: > This would be a bad idea in the same way that having control characters in > filenames is a bad idea, just because you can do something doesn't mean you > should. I would personally advocate NOT to use it in code. But then, I am biassed by upbringing towards ASCII... But, I wouldn't want others to be deprived of the option. Remember, function names, and aliases already can be in unicode encodings! Which probably already helps shell endusers the most. But allowing variable names in unicode is a logical progression, and as we can see from Eduardo's quick patch, doesn't involve a big overhead in added complexity. (Advocating because of living now in a country with a different script.) Peter
[PATCH] Memory leak in locale.c set_default_locale
Found by running the test suite under ASAN.
=
==3298==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 12 byte(s) in 1 object(s) allocated from:
#0 0x7f2b94db1d28 in malloc
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
#1 0x558589eb06d6 in xmalloc
(/home/dualbus/src/gnu/bash-build/bash+0x14f6d6)
#2 0x558589ea2c62 in set_default_locale
(/home/dualbus/src/gnu/bash-build/bash+0x141c62)
#3 0x558589de17f0 in main
(/home/dualbus/src/gnu/bash-build/bash+0x807f0)
#4 0x7f2b945442b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
SUMMARY: AddressSanitizer: 12 byte(s) leaked in 1 allocation(s).
*** /tmp/R6GbnO_locale.c2017-06-07 20:40:25.575118629 -0500
--- locale.c2017-06-07 20:39:59.054419575 -0500
***
*** 85,91
textdomain (PACKAGE);
locale_mb_cur_max = MB_CUR_MAX;
! locale_utf8locale = locale_isutf8 (default_locale);
locale_shiftstates = mblen ((char *)NULL, 0);
}
--- 85,98
textdomain (PACKAGE);
locale_mb_cur_max = MB_CUR_MAX;
! locale_utf8locale = 0;
! #if defined (HAVE_SETLOCALE)
! if (default_locale)
! {
! locale_utf8locale = locale_isutf8 (default_locale);
! free (default_locale);
! }
! #endif /* HAVE_SETLOCALE */
locale_shiftstates = mblen ((char *)NULL, 0);
}
--
Eduardo Bustamante
https://dualbus.me/
