The ^-Character does not work in MongoShell when writing a regular expression.
No matter how often I hit the key or try to enter the ASCII code, the character does not appear in the command line of the MongoShell
14 KB
6 KB
4 KB
15 KB
I cannot reproduce the reported problem. The " ^ " can be successfully entered on my test scenario. See attached screenshot.
Please provide more details about the context when you are encountering this problem.
@zhatyr: see attached screenshot in which I've inputted 2 caret (^) characters in MongoShell. You are not able to do this?
Are you able to input a caret character in Query Analyzer?
Also, ADS offers the ability to register an SSH server by going to the menu Server > Register SSH server. Can you register an SSH server, connect to it & let us know whether you're able to input a caret character?
@zhatyr: see attached screenshot in which I've inputted 2 caret (^) characters in MongoShell. You are not able to do this?
Are you able to input a caret character in Query Analyzer?
Also, ADS offers the ability to register an SSH server by going to the menu Server > Register SSH server. Can you register an SSH server, connect to it & let us know whether you're able to input a caret character?
I am able to reproduce this issue using german keyboard layout. On this layout, the caret char is located on left-hand-side of the "1" key. However, under Ubuntu I have to hit this key twice in order to input the caret char. It works this way under Query Analyzer Window and all other OS applications (including console window) but fails within ADS MongoShell window.
If zhatyr also had to hit this key twice in order to input the caret key, then this condition might represent the key for debugging and fixing the issue.
I am able to reproduce this issue using german keyboard layout. On this layout, the caret char is located on left-hand-side of the "1" key. However, under Ubuntu I have to hit this key twice in order to input the caret char. It works this way under Query Analyzer Window and all other OS applications (including console window) but fails within ADS MongoShell window.
If zhatyr also had to hit this key twice in order to input the caret key, then this condition might represent the key for debugging and fixing the issue.
Typing the " ` " key twice inside MongoShell window using german keyboard layout resulted in failure to input the caret ( ^ ) key , but I have succeeded to input it by hitting the " ` " key followed by the SPACE key.
@zhatyr : Are you able to enter the caret key ( ^ ) within MongoShell if you hit the " ` " key followed by the SPACE key?
The " ` " key is a dead key on german keyboard layout, thus can be used in combination with other characters to generate a character with an accent on it (e.g. â ê ô etc. ).
Later edit: Due to the "dead key" nature of the " ` " key, it turns out that the << " ` " followed by SPACE key >> combination works only on limited scenarios under MongoShell. I'll debug the underlying GUI component to see what causes these input failures.
Typing the " ` " key twice inside MongoShell window using german keyboard layout resulted in failure to input the caret ( ^ ) key , but I have succeeded to input it by hitting the " ` " key followed by the SPACE key.
@zhatyr : Are you able to enter the caret key ( ^ ) within MongoShell if you hit the " ` " key followed by the SPACE key?
The " ` " key is a dead key on german keyboard layout, thus can be used in combination with other characters to generate a character with an accent on it (e.g. â ê ô etc. ).
Later edit: Due to the "dead key" nature of the " ` " key, it turns out that the << " ` " followed by SPACE key >> combination works only on limited scenarios under MongoShell. I'll debug the underlying GUI component to see what causes these input failures.
However, under Ubuntu I have to hit this key twice in order to input the caret char. It works this way under Query Analyzer Window and all other OS applications (including console window) but fails within ADS MongoShell window.
@emil: How about once you've registered an SSH server in ADS & then connect to it via ADS. Same issue as in MongoShell?
However, under Ubuntu I have to hit this key twice in order to input the caret char. It works this way under Query Analyzer Window and all other OS applications (including console window) but fails within ADS MongoShell window.
@emil: How about once you've registered an SSH server in ADS & then connect to it via ADS. Same issue as in MongoShell?
I'm running Windows 10 64bit with a germany keyboard layout.
I also attached two screenshots.
As you can see in mongoshell_in_cmd, I can enter the caret there. hitting the key followed by a space just works fine there.
On the other screenshot (mongoshell_in_ads) you can see on the top, that I copied the find-command from my mongoshell running in cmd.exe and it shows the ^-character, the find command works.
But when I try to enter the character manually, it does not work.
Seems as if this might be a problem with my computer and I will try to reproduce it on another machine.
I have not tried to register an ssh server in ADS and will do this tonight.
Thank you for your help so far.
I'm running Windows 10 64bit with a germany keyboard layout.
I also attached two screenshots.
As you can see in mongoshell_in_cmd, I can enter the caret there. hitting the key followed by a space just works fine there.
On the other screenshot (mongoshell_in_ads) you can see on the top, that I copied the find-command from my mongoshell running in cmd.exe and it shows the ^-character, the find command works.
But when I try to enter the character manually, it does not work.
Seems as if this might be a problem with my computer and I will try to reproduce it on another machine.
I have not tried to register an ssh server in ADS and will do this tonight.
Thank you for your help so far.
@emil: How about once you've registered an SSH server in ADS & then connect to it via ADS. Same issue as in MongoShell?
This issue is reproducible using german keyboard layout inside ADS SSH console as well.
@emil: How about once you've registered an SSH server in ADS & then connect to it via ADS. Same issue as in MongoShell?
This issue is reproducible using german keyboard layout inside ADS SSH console as well.
Test scenarios using german keyboard layout:
Scenario 1: type few alpha-numeric chars, then try to enter the caret key by either hitting the " ` " key twice or hit once followed by the space key.
Result: Caret key is successfully entered.
Scenario 2: type few alpha-numeric chars, move cursor using arrow keys, then try to enter the caret key by either hitting the " ` " key twice or hit once followed by the space key.
Result: Caret key is not displayed.
The root cause of this issue was the logic implemented inside the Term class (the "passOn" flag) which assumes that the keyPressed() event always occurs before the keyTyped() one. However, this assumption is not valid when dead key is used to enter chars such as caret one on german keyboard layout.
In order to fix this issue, the "passOn" flag should be reset inside the keyReleased() method.
Test scenarios using german keyboard layout:
Scenario 1: type few alpha-numeric chars, then try to enter the caret key by either hitting the " ` " key twice or hit once followed by the space key.
Result: Caret key is successfully entered.
Scenario 2: type few alpha-numeric chars, move cursor using arrow keys, then try to enter the caret key by either hitting the " ` " key twice or hit once followed by the space key.
Result: Caret key is not displayed.
The root cause of this issue was the logic implemented inside the Term class (the "passOn" flag) which assumes that the keyPressed() event always occurs before the keyTyped() one. However, this assumption is not valid when dead key is used to enter chars such as caret one on german keyboard layout.
In order to fix this issue, the "passOn" flag should be reset inside the keyReleased() method.
From Emil:
The "passOn" flag seems that has been introduced in order to suppress forwarding of certain keystrokes during keyPressed() -> keyTyped() -> keyReleased() flow. The fix made for #13901 resets the "passOn" flag on the keyReleased() event, which I think does not impact the original algorithm logic.
From Emil:
The "passOn" flag seems that has been introduced in order to suppress forwarding of certain keystrokes during keyPressed() -> keyTyped() -> keyReleased() flow. The fix made for #13901 resets the "passOn" flag on the keyReleased() event, which I think does not impact the original algorithm logic.
@zhatyr: We have a patch for you to test. Pls let us know whether this resolves your issue or not.
@zhatyr: We have a patch for you to test. Pls let us know whether this resolves your issue or not.
@SachinPrakash: Unfortunately the behaviour is still the same, no matter if I hit the key several times or hit the space key after a dead key like "^" key
@SachinPrakash: Unfortunately the behaviour is still the same, no matter if I hit the key several times or hit the space key after a dead key like "^" key
Indeed, there was an additional problem when ADS was run on Windows machines. The root cause was that the Term.maybeConsume() method was invoking KeyEvent#consume() on events (received via keyPressed() ) that were fired when a dead key was pressed for the first time. Because this event was consumed, when user was pressing the dead key followed by the SPACE one, the keyTyped(SPACE) was later fired instead of the expected keyTyped(CARET) one.
The solution is to avoid invoking KeyEvent#consume() when dead keys are pressed, thus allowing the JVM to correctly process the dead key combination (the two key strokes sequence) and then fire adequate keyTyped() event.
Indeed, there was an additional problem when ADS was run on Windows machines. The root cause was that the Term.maybeConsume() method was invoking KeyEvent#consume() on events (received via keyPressed() ) that were fired when a dead key was pressed for the first time. Because this event was consumed, when user was pressing the dead key followed by the SPACE one, the keyTyped(SPACE) was later fired instead of the expected keyTyped(CARET) one.
The solution is to avoid invoking KeyEvent#consume() when dead keys are pressed, thus allowing the JVM to correctly process the dead key combination (the two key strokes sequence) and then fire adequate keyTyped() event.
@zhatyr: We have a fix for you. We've verified the fix in our Windows environment. Pls let us know whether this resolves your issue or not.
@zhatyr: We have a fix for you. We've verified the fix in our Windows environment. Pls let us know whether this resolves your issue or not.
@SachinPrakah: Sorry for the late reply. But I can tell you, that the dead keys now work like a charm!
@SachinPrakah: Sorry for the late reply. But I can tell you, that the dead keys now work like a charm!
Issue #13901 |
Closed |
Fixed |
Resolved |
Completion |
No due date |
Fixed Build 16.0.10-3 |
No time estimate |
I cannot reproduce the reported problem. The " ^ " can be successfully entered on my test scenario. See attached screenshot.
Please provide more details about the context when you are encountering this problem.