12 results found

1. Vi mode for MongoDB Shell

   Please enable a 'vi' editing mode for the mongo shell.

   • Similar to vi mode in bash
   • Similar to https://www.npmjs.com/package/mongovi

   A first cut of key bindings would be:

   Basic command mode/editing mode toggling:
   i Insert before cursor
   Esc Toggle to command mode

   Cursor motion keys:
   h Move left
   j Move down
   k Move up
   l Move right

   w Move to next word
   b Move to the beginning of the word

   0 Move to the beginning of the line
   $ Move to the end of the line

   And delete/change:
   x delete next character to the right
   d

   {motion} delete amount specified by {motion}
   c

   {motion} delete amount specified by {motion}
   and also put you in insert mode

   Please enable a 'vi' editing mode for the mongo shell.

   • Similar to vi mode in bash
   • Similar to https://www.npmjs.com/package/mongovi

   A first cut of key bindings would be:

   Basic command mode/editing mode toggling:
   i Insert before cursor
   Esc Toggle to command mode

   Cursor motion keys:
   h Move left
   j Move down
   k Move up
   l Move right

   w Move to next word
   b Move to the beginning of the word

   0 Move to the beginning of the line
   $ Move to the end of the line

   And delete/change:
   x delete next character to the right
   d

   {motion} delete amount specified by… more

   11 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   3 comments  ·  Usability  ·  Delete…  ·  Admin →
   completed  ·  AdminGaurab (Admin, MongoDB) responded

   
   

2. Add support for AWS_PROFILE when authMechanism is MONGODB-AWS

   Currently, when using MONGODB-AWS, it can only read the following variables:

   AWS ACCESS KEY ID
   AWS SECRET ACCESS KEY
   AWS SESSION TOKEN

   which forces you to export credentials or to paste them in the CLI.

   AWS has a variable called AWS_PROFILE that will fetch the required values from your credential file, without having to paste them again. This variable is supported by anything using AWS SDK, so mongosh should have support for it as well.

   10 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Commands  ·  Delete…  ·  Admin →
   completed  ·  AdminGaurab (Admin, MongoDB) responded

   Hi there,

   
   

   Thank you for your feedback. We wanted to let you know this issue has been resolved starting mongosh version 2.2.0. Please find the latest version of mongosh here: https://www.mongodb.com/try/download/shell.

   
   

   Please let us know how else we could make your MongoDB Shell experience better!

3. Support .mongorc.js file

   A core bit of functionality from the original shell is to support reading from the .mongorc.js file in a user's home directory. This feels like core functionality that mongosh should support.

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Usability  ·  Delete…  ·  Admin →
   completed  ·  AdminMassimiliano (Admin, MongoDB) responded

   This is available in mongosh 0.10.0+

4. Ability to execute a javascript file from inside the shell

   Currently the only way to execute a javascript file from the mongo shell is to re-direct the input at shell login time (e.g. mongo --username <username> ... < myscript.js). It would be helpful to have a way to execute the script from inside the shell via some sort of "run" command (e.g.from inside the shell "run /my/path/myscript.js".

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Commands  ·  Delete…  ·  Admin →
   completed  ·  AdminMassimiliano (Admin, MongoDB) responded

   Mongosh 0.10.0+ supports load() which seems to be exactly what you need. Please let me know if that is not what you had in mind.

5. Bracket matching and highlighting

   Something which I miss from the legacy shell is bracket matching and highlighting, so I can tell when I have too many brackets, or they're in the wrong order

   •  

   •  

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Usability  ·  Delete…  ·  Admin →
   completed  ·  AdminMassimiliano (Admin, MongoDB) responded

   This is available starting in version 0.15.5

6. Edit command like the old mongo shell has

   It would be nice to have the edit feature of the old mongo shell https://docs.mongodb.com/manual/tutorial/configure-mongo-shell/#use-an-external-editor-in-the-mongo-shell

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Commands  ·  Delete…  ·  Admin →
   completed  ·  AdminMassimiliano (Admin, MongoDB) responded

   This is completed and released in mongosh 1.1.0.

   Let us know if you have any feedback about this feature or about the shell in general.

7. mongosh and JSON: normalized output

   The CLI commands, like mongosh, can be used in bash scripts to quickly implement reliable data processing pipelines. Thanks to the aggregation pipeline your clients can do pretty complex things with this, despite a small number of lines and zero infrastructure. Unfortunately, in the recent versions, the output of those commands is no longer JSON. When mongosh returns results, it is now in pseudo-JSON, which can no longer be parsed directly by other standard tools like jq. This makes interpreting the results needlessly complicated. In addition, error messages are not output in JSON either (simple unformatted strings in that case), which adds another useless layer of complexity to handle the various errors.

   My suggestion is that all the CLI tools, especially mongosh, should always output (or have at least an option to do so) its results, messages, and errors in a standard JSON format that can be readily consumed by other standard tools. Hopefully, you guys can find a way to expand the resulting JSON structures while retaining their backward compatibility as much as possible, instead of redefining the same fields' types over and over. This would make using those commands reliably inside scripts a breeze.

   Note: I understand that the results might contain stuff like ObjectId() which are not JSON, but in that case, it is possible to rewrite them as { ..., ObjectId : "asdasd", ... } or { ..., ObjectIds : ["asda", "err34e", ...], ...}.

   The CLI commands, like mongosh, can be used in bash scripts to quickly implement reliable data processing pipelines. Thanks to the aggregation pipeline your clients can do pretty complex things with this, despite a small number of lines and zero infrastructure. Unfortunately, in the recent versions, the output of those commands is no longer JSON. When mongosh returns results, it is now in pseudo-JSON, which can no longer be parsed directly by other standard tools like jq. This makes interpreting the results needlessly complicated. In addition, error messages are not output in JSON either (simple unformatted strings in that case),… more

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Scripting  ·  Delete…  ·  Admin →
   completed  ·  AdminMassimiliano (Admin, MongoDB) responded

   Starting with mongosh 1.6.0, it's now possible to pass a `--json` parameter to mongosh in conjunction with 

   `--eval`. For example:

   
   

   $ mongosh $CONNECTION_STRING --eval 'db.coll.stats()' --json=relaxed --quiet | jq '{storageSize,totalSize}'
   {
    "storageSize": 36864,
    "totalSize": 184320
   }

   
   

   If instead you are looking for a way to output JSON from a script, you can use `EJSON.stringify(thingToOutput, null, 2)`.

8. Mongosh connection string thourgh proxy

   Greetings,
   I need to create a proxy host in my environment so that ALL traffic between client <->Mongo Atlas goes through ONE single host.
   Problem is that if I use mongodb+srv://server.example.com/
   It returns me one of 50 endpoints to my Atlas cluster.

   I need something like: connect to this cluster, BUT use this proxy hop server.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   completed  ·  1 comment  ·  Usability  ·  Delete…  ·  Admin →

9. Deal with // comments multiline history better

   This is a papercut in the legacy shell which would make the modern shell even more usable by comparison...

   Currently, both the new and legacy shell have an issue with the way they store a multiline command (eg. when defining an aggregation pipeline) as a single line in its history.

   Often (especially for aggregation pipelines) inputted commands will contain // comments. For example, see the code snippet 'var pipeline = [...];' here: https://www.practical-mongodb-aggregations.com/examples/simple-examples/group-and-total.html

   The reason why this shell behaviour is problematic is discussed in the Practical MongoDB Aggregations book chapter at https://www.practical-mongodb-aggregations.com/guides/composibility.html
   (scroll 2/3 down that page and read the 'punchout' text shown)

   In short, if the command contains '//' comments it breaks when re-run from the history (even if the history command is not edited by the user). Need a way to allow the command to still be re-executed from history without failing (whether edited inline or left as-is, before re-running).

   I don't have one single way to recommend about how this should be implemented, but some options (each with likely relative pros/cons) are:

   1. When saving a multi-line command, in the shell's history, replace // comments with /.../ commands (but would have to be careful if some of the text already containing /.../ comments).

   2. Store the version of the command retaining multi-line characters but then only show it in the history as a single line (this would be fine for just pressing Up followed by Execute, but might be problematic when editing the command between Up and Execute).

   This is a papercut in the legacy shell which would make the modern shell even more usable by comparison...

   Currently, both the new and legacy shell have an issue with the way they store a multiline command (eg. when defining an aggregation pipeline) as a single line in its history.

   Often (especially for aggregation pipelines) inputted commands will contain // comments. For example, see the code snippet 'var pipeline = [...];' here: https://www.practical-mongodb-aggregations.com/examples/simple-examples/group-and-total.html

   The reason why this shell behaviour is problematic is discussed in the Practical MongoDB Aggregations book chapter at https://www.practical-mongodb-aggregations.com/guides/composibility.html
   (scroll 2/3 down that page and read the… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   completed  ·  AdminMassimiliano (Admin, MongoDB) responded

   Starting with version 1.0.6 of mongosh, single-line comments are replaced with /**/.

   There is no simple way to retain multi-line in history but I will split that into a separate suggestion to keep track of it.

10. Control-C to cancel current execution only - without exiting from mongo shell

    when you started some complex query and realized that it could take time - you want to cancel it. if you press Control-C you will be kicked out of mongo shell. so you have to login back and switch to proper database; probably, set all variables again etc.

    there should be option to cancel just current execution leaving you in current session.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Usability  ·  Delete…  ·  Admin →
    completed  ·  AdminMassimiliano (Admin, MongoDB) responded

    This is available in mongosh 0.13.1+. When you do Ctrl-C, the shell will attempt to cleanly kill the operation on the server and get you back to the prompt right away.

11. Add history search

    Add ability to search through the command history using Cmd/Ctrl+R. It would be nice to also being able to search through the scripts entered with .editor

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    completed  ·  2 comments  ·  Usability  ·  Delete…  ·  Admin →

12. Allow for session timeouts

    For security reasons, it should be possible to configure a session timeout after which, if there has been no activity, the shell disconnects from MongoDB and the user has to reconnect.

    0 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    completed  ·  1 comment  ·  Security  ·  Edit…  ·  Delete…  ·  Admin →