Solved cursor is gone

Solved issue

Diputs

Active Member
Joined
Jul 28, 2021
Messages
133
Reaction score
48
Credits
1,023
I had this Bash script I was using on a Red Hat (Oracle really) Linux 7 machine, which was working all fine.

Suddenly, without me changing the script (I think), the following happens:

The script just runs fine, BUT
... my cursor is gone. It's just not there. I can type, no problem, but you can't see where, before you actually type.
Also, ALL keys on the keypad, don't work from that same moment on.
I can exit my script, but the issue just continues, until I exit from that account
(Or, when I exit my Putty session - not sure there)

Some code in my script is activating this behaviour, but there's definately nothing in there that would try something in that area. I need to find the code that does, but until then I'm a bit clueless.
 


I'm not an expert on controlling a cursor but maybe these links with suggestions will help.


Poke around in the devices subsystem to see what is presenting /dev/input/mouse0.

 
Good thing we are all mind readers here. I’m getting the vibe the problem is somewhere in line 13 of your script because 13 is an unlucky number.
 
I'm not an expert on controlling a cursor but maybe these links with suggestions will help.


Poke around in the devices subsystem to see what is presenting /dev/input/mouse0.


I'm not trying to control my cursor or keypad, the cursor and keypad are broken. Consistenly, and only when running that script. So, apparently, I've written hack code with just IF statements ... cool. It's not even running as root. How exactly am I changing the system behaviour, as non-root ?
 
Good thing we are all mind readers here. I’m getting the vibe the problem is somewhere in line 13 of your script because 13 is an unlucky number.

That's not really the question. The question is more: how does some very normal code, manage to have that effect. Just a hint: I run the same script on another version of this same Linux distro, and it never happens there.
 
Good thing we are all mind readers here. I’m getting the vibe the problem is somewhere in line 13 of your script because 13 is an unlucky number.

Great humor for the day!
I needed to smile-:)
 
That's not really the question. The question is more: how does some very normal code, manage to have that effect. Just a hint: I run the same script on another version of this same Linux distro, and it never happens there.
Sounds like it could be a bug or yet another Linux mystery.

Sharing your script may help.
 
Sounds like it could be a bug or yet another Linux mystery.

Sharing your script may help.

Yes, to me it sounds like a bug as well. Mysteries ... I call that : unsolved bugs.

It's not legal for me to share the code.
But, I'm pretty sure you wouldn't find it even if I showed the code, since there's no obvious call to disable a keypad or such.

The question basically is: is there a bug in Bash, that causes that behaviour. You don't need to know my code, to answer that, if the bug exists.
 
Yes, to me it sounds like a bug as well. Mysteries ... I call that : unsolved bugs.

It's not legal for me to share the code.
But, I'm pretty sure you wouldn't find it even if I showed the code, since there's no obvious call to disable a keypad or such.

The question basically is: is there a bug in Bash, that causes that behaviour. You don't need to know my code, to answer that, if the bug exists.
Maybe give some debugging tools a try.
 
That's not really the question. The question is more: how does some very normal code, manage to have that effect. Just a hint: I run the same script on another version of this same Linux distro, and it never happens there.
Ever heard of sarcasm.
Sharing your script may help.
That was what I was looking so we could actually see what your script does.

Yes, to me it sounds like a bug as well. Mysteries ... I call that : unsolved bugs.

It's not legal for me to share the code.
But, I'm pretty sure you wouldn't find it even if I showed the code, since there's no obvious call to disable a keypad or such.

The question basically is: is there a bug in Bash, that causes that behaviour. You don't need to know my code, to answer that, if the bug exists.
Since that is not possible, then I would say since it works on one version of Oracle Linux 7.x and not on another version of Oracle Linux 7.x, then compare the two bash versions. On the Oracle Linux version where it doesn't work downgrade or upgrade the bash version to the same version of the Oracle Linux 7.x version where it does work. You can use yumdownloader, something like this.
1. log into system where your script works fine
2. yumdownloader bash
3. Copy the rpm file to the system where the problem occurs.
4. Login to the system where the problem occus
5. Install it: yum localinstall bash.86_64.rpm
6. Run the script again and see what happens.

If we that version of bash the script also runs without any problems there must be a bug or problem in bash or that version which which is compiled by Redhat, if not than the problem is else where. It also might be an idea to run the script on another distribution, such as Fedora or Debian(if there are not rhel specific commands used in your script) if the problem still occurs to see what happens then. I hope that helps, good luck! ;)
 
Last edited:
By the way, found the isee - Linux bug indeed
So what was the bug and how did you find it, did you try what I suggested?
 
I can recreate the symptoms by means of running this script:

-------------------------------------
#!/bin/bash

top -n 3 | head -n 10
-------------------------------------

Note, the same issue does NOT occur if you run either
top -n 3
or even:
top

Also note, the issue is exactly the same, if you run " top -n 3 | head -n 10 "
from the command line.
 

Members online


Latest posts

Top