| Bug #73334 | command line parameter for executing python scripts not working | ||
|---|---|---|---|
| Submitted: | 20 Jul 2014 15:41 | Modified: | 5 Sep 2014 4:52 |
| Reporter: | Johannes Taxacher | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Workbench | Severity: | S3 (Non-critical) |
| Version: | 6.1.7 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[28 Aug 2014 15:09]
Johannes Taxacher
Posted by developer: fix verified in 6.2.2
[5 Sep 2014 4:52]
Philip Olson
Fixed as of the upcoming MySQL Workbench 6.2.2 release, and here's the changelog entry: The "--script" parameter, which is meant to load an SQL script into a query editor, will now explicitly emit a warning when it is mistakenly used with a Python script. Thank you for the bug report.
Description: Workbench offers several parameters to pass a script-file on launch that should be executed. The parameters currently offered by the help output are "script", "run-script" and "run-python". According to the commandline help, the first ("-script") should "Open the given SQL file in an connection ...". Despite the information in the help output, the "-script" parameter did properly execute python files in Workbench up to version 6.1.6. Version 6.1.7 though does not react in any visible way when passing in a python file this way (no output visible on cmd-line, output-pane or message of any other kind). If the behavior has been changed to only accept SQL files from now, WB should give a proper response to the user when trying to use it with an unsupported filetype. "-run-python" or "-run-script" on the other hand sound like the better choices when it comes to executing .py scripts using workbench - but these simply output some rather meaningless err messages (for files that run flawlessly when executed using the scripting shell GUI). How to repeat: execute this on a commandline (using a python file that prints some output): MySQLWorkbench -script myPythonFile.py -quit-when-done Workbench will only briefly open and close again (the close is of course due to the "-quit-when-done" parameter, but omitting that one won't change the behavior on Workbench for the script file)