PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
Since upgrading to OS X 10.10 Yosemite and thus bash 3.2.53 use of the PROMPT_COMMAND='history -a; history -n' workaround to get a single ksh-style history causes the shell to become less and less responsive until it permanently hangs. The problem is somewhat intermitant in terms of how quickly it starts, but it's more pronounced after a su - to root (or probably any su). It can be readily reproduced by: 1) Putting the above command in your .bashrc file 2) Start a new terminal session 3) su - 4) Hit return around 20-40 times (optionally entering commands) 5) Watch as the prompt returns more and more slowly, then never at all, and PS reports ~98% CPU usage for bash. For a complete description, please see this stack exchange post: http://apple.stackexchange.com/questions/153361/prompt-command-history-a-history-n-changed-broken-in-yosemite-bash-3-2 http://apple.stackexchange.com/questions/153361/prompt-command-history-a-history-n-changed-broken-in-yosemite-bash-3-2
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On 10/29/14, 1:31 AM, Graham Jones wrote: Since upgrading to OS X 10.10 Yosemite and thus bash 3.2.53 use of the PROMPT_COMMAND='history -a; history -n' workaround to get a single ksh-style history causes the shell to become less and less responsive until it permanently hangs. I wasn't able to reproduce this on 10.10, but there are a lot of variables and potential environmental dependencies here. What would be useful is some kind of backtrace (from lldb or gdb) or a system call trace (from dtruss or ktrace) that shows what bash is doing. 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/
feature: time builtin and file descriptor
Hello, Would it make sense to add to 'time' builtin a way to measure how long a file descriptor is been kept open? Something like this. -- snip #!/bin/bash exec 420 time --file-descriptor 42 sleep 10 exec 42- -- snip $ ./above_script.sh real0m10.012s user0m0.000s sys 0m0.000s This idea came to my mind while writing a script that runs multiple commands, and I simply wanted to know how long they are busy. I am aware alternatives exist, but they can get a bit tricky if one wants to have multiple measurements going on simultaneously. For example: exec 420 time --file-descriptor 42 for i in items; in exec 520 time --file-descriptor 52 echo processing $i [...] echo item $i took exec 52- done echo 'all together took:' exec 42- What do you think, useful feature or unnecessary bloat? -- Sami Kerola http://www.iki.fi/kerolasa/
Re: feature: time builtin and file descriptor
On Wed, Oct 29, 2014 at 02:09:53PM +, Sami Kerola wrote: Would it make sense to add to 'time' builtin a way to measure how long a file descriptor is been kept open? Doesn't really make much sense. If you want multiple independent timers, there's no reason to tie them to open file descriptors. If anything, just make an array of timers, with some shell builtin to start and stop each one. Read the array element to get the elapsed time. I can't say I've ever had a need for this. This idea came to my mind while writing a script that runs multiple commands, and I simply wanted to know how long they are busy. I am aware alternatives exist, but they can get a bit tricky if one wants to have multiple measurements going on simultaneously. Without any shell modifications, if your operating system provides %s in strftime() then you can get the current time with second resolution (and without forking date) by doing: printf -v somevariable '%(%s)T' -1 It's not much additional effort to keep separate variables (possibly array elements) for each independent timer you want to track. Issue the same printf command again to get the end time, and subtract. If you need millisecond (or even smaller) resolution, or if you need it to work on non-Linux/BSD systems, then I'm afraid Bash is just not the right language for your project.
Re: [PATCH] bracketed paste support
On 10/29/2014 09:35 PM, Pádraig Brady wrote:
On 10/27/2014 10:35 PM, Daniel Colascione wrote:
+@item enable-bracketed-paste
+@vindex enable-bracketed-paste
+If set to @samp{on} and the terminal supports bracketed paste mode,
+configure it to insert each paste into the editing buffer as a string
+instead of treating the characters pasted as normal input, preventing
+inadvertent execution of pasted commands. The default is @samp{on}.
I see this defaults on.
Does this mean one can't paste command sequences to readline now?
Well, I don't know whether Chet left the feature enabled by default. I hope he
did, though, since preventing execution of pasted commands is one of the
feature's key benefits. In bash, you should be able to execute a pasted command
sequence by typing RET after the paste, but a paste by itself should never
begin execution.
For better or worse, people copy and paste commands from websites all the time.
Even if a bit of shell looks innocuous, a malicious bit of JavaScript could
change the pasted text at the last second without the user being aware of the
switch. (Tynt uses this technique to slightly less malicious ends.) If pasting
in a terminal immediately begins execution, there's no opportunity to review
pasted code. With bracketed paste support, the shell requires additional user
interaction after a paste to begin execution, making this attack much less
effective.
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] bracketed paste support
On 10/29/2014 09:42 PM, Daniel Colascione wrote:
On 10/29/2014 09:35 PM, Pádraig Brady wrote:
On 10/27/2014 10:35 PM, Daniel Colascione wrote:
+@item enable-bracketed-paste
+@vindex enable-bracketed-paste
+If set to @samp{on} and the terminal supports bracketed paste mode,
+configure it to insert each paste into the editing buffer as a string
+instead of treating the characters pasted as normal input, preventing
+inadvertent execution of pasted commands. The default is @samp{on}.
I see this defaults on.
Does this mean one can't paste command sequences to readline now?
Well, I don't know whether Chet left the feature enabled by default. I hope
he did, though, since preventing execution of pasted commands is one of the
feature's key benefits. In bash, you should be able to execute a pasted
command sequence by typing RET after the paste, but a paste by itself should
never begin execution.
For better or worse, people copy and paste commands from websites all the
time. Even if a bit of shell looks innocuous, a malicious bit of JavaScript
could change the pasted text at the last second without the user being aware
of the switch. (Tynt uses this technique to slightly less malicious ends.) If
pasting in a terminal immediately begins execution, there's no opportunity to
review pasted code. With bracketed paste support, the shell requires
additional user interaction after a paste to begin execution, making this
attack much less effective.
Requiring the extra RET after pasting shouldn't be too onerous.
I found this to be a good summary:
http://cirw.in/blog/bracketed-paste
Thanks for the extra info!
Pádraig.
Re: [PATCH] bracketed paste support
On 10/29/14 5:35 PM, Pádraig Brady wrote:
On 10/27/2014 10:35 PM, Daniel Colascione wrote:
+@item enable-bracketed-paste
+@vindex enable-bracketed-paste
+If set to @samp{on} and the terminal supports bracketed paste mode,
+configure it to insert each paste into the editing buffer as a string
+instead of treating the characters pasted as normal input, preventing
+inadvertent execution of pasted commands. The default is @samp{on}.
I see this defaults on.
The version of the patch I put into readline defaults to off.
Does this mean one can't paste command sequences to readline now?
No.
--
``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: feature: time builtin and file descriptor
On 10/29/14 10:09 AM, Sami Kerola wrote: Hello, Would it make sense to add to 'time' builtin a way to measure how long a file descriptor is been kept open? Something like this. You can use $SECONDS for this, but you have to do the math and keep track of the file descriptors yourself. 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/
