Re: Bugfix: builtins/history: Check return value from localtime
On 1/19/18 11:06 PM, Luke Dashjr wrote: > Somehow some of my bash histories have acquired very large timestamps (eg, > "#143513214935906531") that cause localtime to fail. BASH's history builtin > currently crashes when it encounters this, because it passes the return > value from localtime directly into strftime, resulting in a NULL pointer > dereference. Thanks for the report and patch. -- ``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: In a script, when you kill a process, you get a terminal style message...
On Sun, Jan 21, 2018 at 10:23:52AM -0700, gaze...@xmission.com wrote: > 1) In a script, when you kill a process, you get a terminal style message > about the process being killed. See below for further description. Here's a simpler reproducer (no need for external symlinks or killall): wooledg:~$ cat foo #!/bin/bash sleep 100 & pid=$! kill $pid wait wooledg:~$ ./foo ./foo: line 4: 8615 Terminated sleep 100 And I have to agree, a clean way to turn off job control type messages is something MANY people would love to have. As it is now, the best solution to this problem is actually to switch from bash to a different shell. wooledg:~$ cat foo #!/bin/sh sleep 100 & pid=$! kill $pid wait wooledg:~$ ./foo wooledg:~$ Sad. (That's dash; ksh is also silent.) The only other solution I know is to redirect stderr to /dev/null, but that has repercussions that a serious program cannot live with.
Re: In a script, when you kill a process, you get a terminal style message...
On 1/22/18 9:51 AM, Greg Wooledge wrote: > On Sun, Jan 21, 2018 at 10:23:52AM -0700, gaze...@xmission.com wrote: >> 1) In a script, when you kill a process, you get a terminal style message >> about the process being killed. See below for further description. > > Here's a simpler reproducer (no need for external symlinks or killall): > > wooledg:~$ cat foo > #!/bin/bash > sleep 100 & pid=$! > kill $pid > wait > wooledg:~$ ./foo > ./foo: line 4: 8615 Terminated sleep 100 > > And I have to agree, a clean way to turn off job control type messages > is something MANY people would love to have. There are build-time options to disable reporting for SIGPIPE (which is enabled in bash-4.4, so exits due to SIGPIPE aren't reported) and SIGTERM (which is not). There isn't a runtime option to control it. I will probably enable the option that doesn't report exits due to SIGTERM in bash-5.0. 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: In a script, when you kill a process, you get a terminal style message...
On 1/21/18 12:23 PM, gaze...@xmission.com wrote: > Bash Version: 4.3 > Patch Level: 48 > Release Status: release > > > > 2) "shopt -s nullglob" breaks filename tab completion. I found that tab > completion > no longer works after I do that "shopt" command. Do you have bash-completion loaded and programmable completion enabled? If not, please send me a case that reproduces the problem, since I can't reproduce the problem using standard bash word completion. -- ``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: In a script, when you kill a process, you get a terminal style message...
On 1/21/18 12:23 PM, gaze...@xmission.com wrote: > 3) Using Escape v to edit a command line in vi mode works, but leaves the > keyboard in a funny state. Specifically, it leaves you at the next bash > prompt, but > in "vi mode" - i.e, hitting k displays the previous line in the history > rather than > entering a 'k'. The user effect is that the keyboard appears to be "stuck" > until you > hit ^C to reset things. It just doesn't change the editing mode. If you were in command mode and used `v' to edit and execute the command, you're still in command mode when the edited file completes. You don't have to ^C; you can just use `i' to enter insert mode like usual. The Posix description of this editing command doesn't explicitly state that the command leaves you in insert mode, but I agree that it probably makes more sense to force readline into insert mode at this point. I'll look at that. -- ``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/
