Re: extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`
On 2/10/21 2:10 AM, Mike Frysinger wrote: On 09 Feb 2021 16:40, Chet Ramey wrote: On 2/9/21 11:51 AM, Mike Frysinger wrote: we're on bash-4.3 atm. we would upgrade to the latest if that were actually a reliable process. unfortunately, moving between bash versions is often full of random regressions or changes in behavior. like this one. Interesting. I suppose one person's bug fix is another's "random change." I don't see it in this case, though, since it's a bug fix and making bash do what its documentation said it did. i'm not complaining that the change was made; in fact, my original report never asked for it to change, or declared it a bug, but was clearly asking for confirmation that it was an intended behavioral change. It's your characterization of the change as "random." Clearly, it was not. seems like it should have been included under the compat43 knob since it was changing long standing behavior (bug or otherwise), but it's prob too late for that now too. It would probably have made things easier for you now, but that's not the point of the comapt settings. Those exist as a bridge so people can fix code, and they exist as a function of how many people use the code in question. One report in five years doesn't rise to that level. And you should start using BASH_COMPAT. You'll thank yourself in ten years. i understand your point, but the real world of shipping code doesn't have the luxury of burning the house down for the latest shiny features. I understand that distribution stability means that you'd like to encase the shell in amber. i made no such claim or request. my point is upgrading bash versions is guaranteed to break something, intentional or not. i've maintained bash in distros & products since bash-2.05b, so i understand this is simply the reality of the project. jumping more than one release (i.e. to bash-5.1) introduces much more risk than reward which is why we're only moving to bash-4.4 now, and once that settles, we can look at the next major step. Sure. Waiting five years to do it guarantees that nothing will get fixed or changed once you do. Most reports will generate a "that was fixed in [next release]" response. has this buried nugget: + - shopt_set_debug_mode: make sure error_trace_mode reflects the setting + of extdebug. This one is tentative. Fix from Grisha Levit > + + - shopt_set_debug_mode: call set_shellopts after setting error_trace_mode + or function_trace_mode. Fix from Grisha Levit You could also have looked in the CHANGES file: . Fixed a bug that caused the shell to not enable and disable function tracing with changes to the `extdebug' shell option. bisecting git is a lot faster than digging through changelog files that are inconsistent across projects and trying to figure out what might or might not be relevant. Bisecting git is pretty fast. My point is that once you find the right commit, you have to look at the change log (as you did) to find out what happened and that there are other sources of information to tell you whether or not an individual change is intentional. i wish bash's vcs history had more discrete sets of changes rather than daily code dumps. but it's still an improvement over not having access to any vcs. It has discrete sets of changes, just more than one change. They're works in development. it looks like we can mitigate this with `set -E` after we turn on extdebug. it's unfortunate that there's no way to get extended debug info without also opting in to side-effects like this. all we really want is to get backtrace info for logging messages when we abort down a few layers. If it works for you, great. But extdebug is always going to be for the benefit of the shell debugger. i didn't ask you to change extdebug behavior. i'm asking for subsets of the current extdebug functionality to be exposed without all the other side-effects. e.g. having bash populate the BASH_ARGC & BASH_ARGV env vars for self-introspection. My point is that those features exist for the debugger's use, and exposing them outside the debugger has to come with a benefit that outweighs their cost. For instance, very few people outside the debugger use BASH_ARGV and BASH_ARGC. Yet setting them up had a noticable performance cost when invoking a script with lots of arguments, for example https://lists.gnu.org/archive/html/bug-bash/2018-02/msg00024.html which happens a lot more often than using BASH_ARGV, so bash-5.0 sets up BASH_ARGV and BASH_ARGC at startup only when in debugging mode. (There is some lazy evaluation there so that they will get set up the first time you enable debugging mode, but you still have to have debugging mode set to update them for functions or sourced files). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww
Re: [PATCH] Fix blocking read timeouts at a small probability
On 2/8/21 9:37 AM, Koichi Murase wrote: Instead, I believe, it is more natural to use `select(2)', which is already used to implement `read -t 0'. In the attached patch `0001-Use-select-2-for-the-read-timeout.patch', I used `select(2)' to implement the timeout of `read(2)'. When `select(2)' is unavailable (i.e., `HAVE_SELECT' is defined in `config.h'), it still falls back to the old strategy with `SIGALRM', but I believe most of modern systems support `select(2)'. I tested the behavior with the above test case, and also tested the behavior by hand. Could you take a look at the patch? Thanks for the analysis and patch. I'll take a look. At first glance, I would like to find a simpler way to do it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] Fix blocking read timeouts at a small probability
On 2/10/21 10:21 AM, Chet Ramey wrote: On 2/8/21 9:37 AM, Koichi Murase wrote: Instead, I believe, it is more natural to use `select(2)', which is already used to implement `read -t 0'. In the attached patch `0001-Use-select-2-for-the-read-timeout.patch', I used `select(2)' to implement the timeout of `read(2)'. When `select(2)' is unavailable (i.e., `HAVE_SELECT' is defined in `config.h'), it still falls back to the old strategy with `SIGALRM', but I believe most of modern systems support `select(2)'. I tested the behavior with the above test case, and also tested the behavior by hand. Could you take a look at the patch? Thanks for the analysis and patch. I'll take a look. At first glance, I would like to find a simpler way to do it. I'd also like to know how this is going to work with read -e and readline, since those don't seem to know anything about the timer. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] Fix blocking read timeouts at a small probability
2021年2月10日(水) 23:40 Chet Ramey : > On 2/10/21 10:21 AM, Chet Ramey wrote: > > Thanks for the analysis and patch. I'll take a look. At first glance, I > > would like to find a simpler way to do it. Thank you. Yes, if there is a simpler but still robust and reliable way to do it, that would be nice. Anyway, I want to see an authentic fix but not a partial fix (that looks to work in "most" cases). With a partial fix, there could be some special use cases where the failure rate becomes non-negligible, such as the test case for this time against the previous partial fix. > I'd also like to know how this is going to work with read -e and readline, > since those don't seem to know anything about the timer. OK, that is a good point. I completely forgot about `read -e'. I took a look at `rl_getc (stream)' (lib/readline/input.c). If one wants to switch to this approach, the timeout needs to be specified for the pselect(2) calls in `rl_getc ()'. In that case, I think readline could provide a proper public interface to accept the setting of the timeout. Because readline might be linked with different versions of Bash, the handling of SIGALRM in readline can be left as is, but the new interface for the timeout can be just added? -- Koichi
Re: [PATCH] Fix blocking read timeouts at a small probability
On 2/10/21 11:59 AM, Koichi Murase wrote: I'd also like to know how this is going to work with read -e and readline, since those don't seem to know anything about the timer. OK, that is a good point. I completely forgot about `read -e'. I took a look at `rl_getc (stream)' (lib/readline/input.c). If one wants to switch to this approach, the timeout needs to be specified for the pselect(2) calls in `rl_getc ()'. In that case, I think readline could provide a proper public interface to accept the setting of the timeout. Because readline might be linked with different versions of Bash, the handling of SIGALRM in readline can be left as is, but the new interface for the timeout can be just added? You'll have to hook the timeout code into the pselect/select calls, as you suspect. Take a shot and it and send me what you come up with. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] Fix blocking read timeouts at a small probability
2021年2月11日(木) 7:02 Chet Ramey : > You'll have to hook the timeout code into the pselect/select calls, as you > suspect. Take a shot and it and send me what you come up with. > > Chet Thank you for the comment. I'll try it when I have time this week. Koichi
Re: [PATCH] Fix blocking read timeouts at a small probability
On 2/10/21 6:21 PM, Koichi Murase wrote: 2021年2月11日(木) 7:02 Chet Ramey : You'll have to hook the timeout code into the pselect/select calls, as you suspect. Take a shot and it and send me what you come up with. Chet Thank you for the comment. I'll try it when I have time this week. Let me know what kind of interface you are thinking about. I have a couple of ideas. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] Fix blocking read timeouts at a small probability
2021年2月11日(木) 7:28 Chet Ramey : > On 2/10/21 6:21 PM, Koichi Murase wrote: > > 2021年2月11日(木) 7:02 Chet Ramey : > >> You'll have to hook the timeout code into the pselect/select calls, as you > >> suspect. Take a shot and it and send me what you come up with. > > > > Thank you for the comment. I'll try it when I have time this week. > > Let me know what kind of interface you are thinking about. I haven't started to work on it so haven't yet decided, but I thought, for example, some variable like `rl_timeout_point' to which one can store a time point that the editing times out. Or, if that's not acceptable, prepare a new function `readline_with_timeout (prompt,timeout_duration)'? Anyway, I need to carefully see the existing interface of readline and want to think of what is the natural interface for this new one. > I have a couple of ideas. I'm interested in them. Thank you, Koichi
