PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53

[Graham Jones]

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
 

Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53

[Chet Ramey]

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/

Re: [PATCH] bracketed paste support

[Chet Ramey]

> On 10/27/14, 6:35 PM, Daniel Colascione wrote:
> > This patch adds support for "bracketed paste mode" to readline. In
> > this mode, readline instructs the terminal to wrap pasted strings in
> > special control sequences so that programs can distinguish them from
> > typed input. 
> 
> Thanks for the contribution.  I'll look at the code; the approach seems
> sound.

It went in very easily, though I changed some things around.  This
will be in the next release of bash and readline. 

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

[Sami Kerola]

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 42>&0
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 42>&0
time --file-descriptor 42
for i in items; in
exec 52>&0
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

[Greg Wooledge]

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

[Pádraig Brady]

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?

thanks,
Pádraig.

Re: [PATCH] bracketed paste support

[Daniel Colascione]

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

[Pádraig Brady]

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

[Chet Ramey]

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: [PATCH] bracketed paste support

[Chet Ramey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/29/14 5: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.

I did not default it to enabled.  It's simple enough to turn it on.

I think Padraig is talking about readline command sequences, not shell
commands.  That's the real point of this patch.  You can select text in
a way to avoid executing a shell command on paste, but without this mode
you can't avoid, for instance, a pasted TAB invoking word completion.


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/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlRRkFAACgkQu1hp8GTqdKujsQCgn3i1gd30shHKptZLxcHVJ9BU
4HwAoIwZYM9L4zNs5WH9cBjnsmvVagux
=WX+H
-END PGP SIGNATURE-

Re: feature: time builtin and file descriptor

[Chet Ramey]

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/

Re: [PATCH] bracketed paste support

[Bob Proulx]

Daniel Colascione wrote:
> 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.

I use paste into the shell with an embedded newline in order to
immediately execute a command *a lot*.  If that were removed I would
be very unhappy.

However I read from Chet's replies that this is not the case.  So I am
not worried.  Just voicing a counter opinion that this shouldn't be
removed.  If you want it then you should enable it.  This is like many
other options available in the shell.  They are optional.

> 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. 

Then the browser shouldn't copy it.  The place to fix the problem is
in the browser.  A problem with a browser should not break cutting and
pasting in general.

> (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.

I am very happy this is a feature you like.  However I would hate that
feature.  It should definitely not default to on or it will make
people like me very unhappy.

Bob

Bash ShellShock patches break "at" job submission of bash scripts

[Marshall Giguere]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -Wall
uname output: Linux aten 3.13.0-38-generic #65~precise1-Ubuntu SMP Thu
Oct 9 19:24:01 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.2
Patch Level: 25
Release Status: release

Description:
Submitting a shell script job to "at" either via pipe, or
command line fails.

Repeat-By:
$> echo myjob.sh|at now

   or

$> at -f myjob.sh now

Output:
sh: 118: BASH_FUNC_form%%=() {  while read; do
args=;
sp="";
for i in "$@";
do
if [ "$i" == "%" ]; then
sp="";
continue;
else
if [ "$i" == "$" ]; then
echo $args;
args="";
sp="";
continue;
fi;
fi;
if [ "${i:0:1}" != "@" ]; then
args="$args$sp$i";
else
if [ "${i:1}" != "" ]; then
args="$args$sp$( nth ${i:1} $REPLY)";
else
args="$args$sp$REPLY";
fi;
fi;
sp=" ";
done;
echo $args;
done
}: File name too long
sh: 118: export: BASH_FUNC_form%%: bad variable name



Fix:
None




signature.asc
Description: This is a digitally signed message part