6 results found

1. The new mongosh mangles the output of piped in commands

   With the old mongo shell, you could set up a shell file (called something like mongo_cmd.sh)containing the path to the executable and all the command line switches you wanted like this:
   
/path/to/mongo --norc --quiet --port 26011


   and then in your other script files pipe commands into an invocation of mongocmd.sh like the following:
   ```
   CMDFILE=./mongo_cmd.sh

   STATS=$(echo 'db.stats().ok' | $CMDFILE)
   DBVERSION=$(echo 'db.version()' | $CMDFILE)

   echo "db.stats().ok output:" $STATS
   echo "db.version() output:" $DBVERSION
   ```

   and the output would be this:
   
db.stats().ok output: 1
db.version() output: 6.0.5


   But if you replace mongo with the new shell mongosh in the above, the output becomes garbles with the mongosh shell prompt appearing both before and after each command output:
   
db.stats().ok output: Enterprise s1 [direct: primary] test> 1 Enterprise s1 [direct: primary] test>
db.version() output: Enterprise s1 [direct: primary] test> 6.0.5 Enterprise s1 [direct: primary] test>


   The new mongosh shell should either be fixed to replicate the old shell behaviour, or it should be enhanced with a new command line switch --legacy that can be used to revert the behaviour for that session.

   With the old mongo shell, you could set up a shell file (called something like mongo_cmd.sh)containing the path to the executable and all the command line switches you wanted like this:
   
/path/to/mongo --norc --quiet --port 26011


   and then in your other script files pipe commands into an invocation of mongocmd.sh like the following:
   ```
   CMDFILE=./mongo_cmd.sh

   STATS=$(echo 'db.stats().ok' | $CMDFILE)
   DBVERSION=$(echo 'db.version()' | $CMDFILE)

   echo "db.stats().ok output:" $STATS
   echo "db.version() output:" $DBVERSION
   ```

   and the output would be this:
   
db.stats().ok output: 1
db.version() output: 6.0.5


   But if you replace mongo with the new shell mongosh in the… 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

   1 comment  ·  Scripting  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Better mongo file loading performance

   Manage a faster loading of files in command line to have better perfs for multiple small scripts.

   See Case 01251177.

   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  ·  Scripting  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. mongosh parse mongo url offline

   In scripting easiers and most robust way to pass mongodb connection info using url string. Sometimes though there is need to parse part of it, like database name or specific query params. In NodeJS whathg URL can be used for this, additionally validating url. For mongsh only way at the moment is to perform actual connecion to running mongodb:
   
mongosh "mongodb://127.0.0.1:27017/staging?serverSelectionTimeoutMS=15000&readPreference=secondaryPreferred" --quiet -eval "print(db)"
staging_db

   Would be nice if mongosh can be used to parse mongodb URL and output some part of it wihtout need for actual connection. This use case if for bash scripting, currently working on combination of bash and mongosh scripts for my need and it works out pretty effective.

   In scripting easiers and most robust way to pass mongodb connection info using url string. Sometimes though there is need to parse part of it, like database name or specific query params. In NodeJS whathg URL can be used for this, additionally validating url. For mongsh only way at the moment is to perform actual connecion to running mongodb:
   
mongosh "mongodb://127.0.0.1:27017/staging?serverSelectionTimeoutMS=15000&readPreference=secondaryPreferred" --quiet -eval "print(db)"
staging_db

   Would be nice if mongosh can be used to parse mongodb URL and output some part of it wihtout need for actual connection. This use case if for bash scripting, currently working on combination of… 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  ·  Scripting  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. add _prettyShell=false to mongosh

   In 4.4, the mongo shell prints 'ugly' by default. Many of our scripts are written to expect this type of output. The mongo shell includes the command: DBQuery.prototype._prettyShell=false to explicitly set this. In mongosh, there is no built in/native ability to achieve the same output as mongo shell.

   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  ·  Scripting  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Change mongosh to process and use arguments only up to a "--" sentinel

   Getting command line arguments into mongosh is virtually impossible.  The --eval option insists on printing the last eval expr evaluated to the console despite the --quiet switch.  Allowing a script to self parse and manage any args following the "–" sentinel using the "process.argv" array would permit the developer a wide array of choices in handling script input from a command line.

   " > mongosh mongo-options script file – arg arg... "

   Component: mongosh

   Versions: 1.4.x and up

   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

   4 comments  ·  Scripting  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Suggest new feature for loading scripts: loadScript and loadFolder

   For loading external script into MongoSh current session, currently we have the load() function, which is enough for the task. But I found myself using my own functions instead. So I would like to describe those as suggestion to improve MongoSh:

   loadScript()

   This function is basically has the same function with load(). But has 1 major difference: all relative paths in the script has the same base directory with the script itself, not the current MongoSh working directory.
   For example:
   - Script "D:\MyProject\src\script.js" have these references: "test.js", "../test2.js"
   - Current working dir process.cwd(): "C:\MongoSh"
   - Path resolved using load("D:\MyProject\src\script.js"): "C:\MongoSh\test.js", "C:\test2.js"
   - Path resolved using loadScript("D:\MyProject\src\script.js"): "D:\MyProject\src\test.js", "D:\MyProject\test2.js"

   My implementation:

   const loadScript = function (name) {
     const currentDir = path.resolve();
     const absPath = path.resolve(name);
     try {
       process.chdir(path.dirname(absPath));
       load(path.basename(absPath));
     } catch (e) {
       print(e);
     }
     process.chdir(currentDir);
   }
   

   loadFolder()

   This function load all scripts in folder and its nested folders (including symbolic links) using loadScript() behavior.

   Why I use this in the first place? Because of .mongoshrc.js. I have a lot of self implement functions, so I put them all in mongoshrc folder in the same location with .mongoshrc.js. And then load them all inside .mongoshrc.js. But since load() function do not interpreted relative path based on script location, so I have to change my working directory like this:

   {
     const currentDir = path.resolve();
     process.chdir(`${process.env.HOME ?? process.env.USERPROFILE}/mongoshrc`);
     load(`myScripts.js`);
     process.chdir(currentDir);
   }
   

   It is better if .mongosh.js loaded with loadScript(), then the script is just:

   loadScript(`mongoshrc/myScripts.js`);
   

   or

   loadFolder(`mongoshrc`);
   

   Hope I make myself clear. Thanks for reading.

   For loading external script into MongoSh current session, currently we have the load() function, which is enough for the task. But I found myself using my own functions instead. So I would like to describe those as suggestion to improve MongoSh:

   loadScript()

   This function is basically has the same function with load(). But has 1 major difference: all relative paths in the script has the same base directory with the script itself, not the current MongoSh working directory.
   For example:
   - Script "D:\MyProject\src\script.js" have these references: "test.js", "../test2.js"
   - Current working dir process.cwd(): "C:\MongoSh"
   - Path resolved… 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  ·  Scripting  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close