Can't reproduce here.
[dave@x3 ~]$ echo $COLUMNS
133
[dave@x3 ~]$ echo $LINES
37

I assume there should be an & after the sleep 10.

What shell are you using?
[dave@x3 ~]$ echo $SHELL
/bin/bash

CC: (none) => davidwhodgins

Sorry, I forgot about the shell info.  This is the default of bash.  I just tested in tcsh and sh, and there it is not a problem.  Backgrounding the sleep command will not trigger the bug, it must be running in the foreground, therefore an ampersand cannot be used.  I.e. this is a bug of running one command before the other has finished - which is quite a normal user command line behaviour.  For the env:

-bash-4.2$ echo $COLUMNS
138
-bash-4.2$ echo $LINES
48

These are of course dependent upon the size of the terminal window.

I am increasing the severity to 'major' as this bug is making it difficult for me to work.  The operation of the bash shell can be considered to be broken.

Severity: normal => major

Without the &, the sleep command will be running in the
foreground, so other commands cannot be run, as the
sleep command will be holding /dev/fd0 (stdin), so bash
will not see the input until after the sleep command has
finished.

I still cannot recreate the problem. Without the &, the
ls doesn't run until after the sleep command has finished,
after which it runs normally.

What do you have in ~/.bash_profile and ~/.bashrc?

For me, the ls command does not run.  Nor does any command in the queue, therein lies the issue.  I tried temporarily removing the ~/.bash_profile and ~/.bashrc files, logged into a VT, and made sure that none of the aliases (using the 'alias' command) and environmental variables (via 'env') were set.  In this test situation, the error occurred.

In another test, I installed Xguest.  This temporary user did not have the problem.

In a third test, I logging into another VT as root (just to be sure the environment is clean).  The root user also suffers from this problem.  The environment for the root is much cleaner as this was newely created with the Mageia 3 install.  I haven't needed to touch the config files since installation:
[root@localhost ~]# cat ~/.bashrc 
# .bashrc

PATH=/usr/local/sbin:/usr/sbin:/usr/local/bin:/usr/bin
ENV=$HOME/.bashrc
USERNAME="root"
export USERNAME ENV PATH

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi
[root@localhost ~]# cat ~/.bash_profile 
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

mesg n
[root@localhost ~]#

Also, /etc/bashrc and /etc/profile have not been modified.  There must be some obsure package triggering this!

Actually, forget the Xguest testing.  This uses rbash rather than bash.  In bash with Xguest, the bug is present.

I think I have just found the bug reported upstream:

http://lists.gnu.org/archive/html/bug-bash/2013-07/msg00054.html

This may be a bug in bash itself rather than perl-Term-ReadKey.

Installing bash from Cauldron (bash-4.2-45.2.mga4.x86_64.rpm) did not fix the problem.

Was this a clean install of Mageia 3 or an upgrade from 2?
How was it installed? (which iso, package groups selected/unselected, etc)
Any third party packages installed?

You're the first person I've seen using bashes ability to queue commands
while one is running.

We need to figure out what's triggering the bug, before it can get fixed.

This was a clean install.  Home directories, excluding root, were preserved on one machine from Mageia 1 and on another from Mandriva 2010.  This should not matter as the non-preserved root home directory results in the same behaviour.  Xguest as well.

These are developement machines used for Python coding (for http://www.nmr-relax.com).  I think the only way for the problem to be solved is for me to create a VM with a new Mageia 3 install using all the packages currently installed on the production machines.  Then I can start to randomly delete RPMs until the problem is isolated.  This might take some time.  I do however believe that comment 7 (https://bugs.mageia.org/show_bug.cgi?id=11032#c7) identifies the real problem.  Following from http://lists.gnu.org/archive/html/bug-bash/2013-07/msg00063.html, if I run:

-bash-4.2$ printenv | grep -P 'ROWS|COLU'
BROWSER=/usr/bin/www-browser
-bash-4.2$

This shows that ROWS and COLUMNS are not exported.  However I do see:

-bash-4.2$ echo $COLUMNS
138
-bash-4.2$ echo $LINES
48

Mageia 3 changed to end-of-life (EOL) status 4 months ago.
http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ 

Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => OLD