Troubleshooting Command Launching & Output

  • Clicking on the Run Button does not launch a Command:
    A Command will not launch if there is no Working Directory specified. We will fix this soon, so that the Run button is not enabled in this case. The workaround for this is just to pick a directory either by Browsing from within the Command View, or by picking a directory in the Navigator View.

  • Pressing <Enter> does not launch a Command:
    There is known problem in the Command View with <Enter> not causing the command to start. We are looking into it. As a workaround, you can click the Run button or if you must use the keyboard...press <Tab> until the Run button is selected, then pressing the <Spacebar> will cause the Command to be run.

  • Trouble cancelling a command or commands that never finish:
    Each command is launched on a background thread, so it is possible that a Cancel request will not be immediately received by a command thread. In some cases, commands may take a several seconds to actually get Canceled. You can tell if a Command is successfully cancelled by checking the Output View for the line "Command Cancelled by User Request"
    We have also found some command combinations that can result in a command that never finishes and can cause the Desktop to slow down. One such command type is the following:
          ls | xargs grep "some text"
    In some extreme cases it may be necessary to kill the "java.exe" process that the Studio Workbench is running in (via Task Manager). This will be fixed shortly.

  • Commands Won't Work on Windows 98:
    There is a limitation on Windows 98 that prevents us from being able to redirect stderr to stdout. If you are running on Windows 98, you will need to edit runCommand.bat which is in the <...>/eclipse/plugins/com.ibm.cpp.core directory and change the line:
          call %THECOMMAND% 2>&1
    to
          call %THECOMMAND%
    This will result in only stdout appearing in the Command Output View. We will address this problem in a future release.

  • If error messages are getting parsed incorrectly or not at all:
    The formats mechanism is only a temporary proof-of-concept. Eventually full regular expression support will be added as well as a clean, integrated way of changing or adding to them. In the meantime, here are the most common causes for formats not parsing output:
    1. Whitespace problems: The biggest weakness with the current formats mechanism is the lack of proper Whitespace control. If a line of output contains "HELLO***SOME_FILE" (where a * is a space), then the format output=TEXT*FILE will NOT match the pattern in the way you might expect. TEXT will match "HELLO" and FILE will match "**SOME_FILE". To correctly match this pattern, you need to change the format to output=TEXT***FILE.

    2. Patterns too general: Output is parsed with the formats in the order they appear in formats.dat. Therefore if you have something like the following in formats:dat:
      error1 = TEXT:FILE
      error2 = TEXT:FILE:LINE
      No output will ever be parsed as an error2 since error1 is more "general" than error2. (Any output that could be parsed as error2 will be parsed as an error1 where the FILE in error1 contains everything after the first ':') So the fix for this case is to switch the order that error1 and error2 appear in formats.dat.

    3. No icons appearing: To get icons appearing for the parsed output, there needs to be an icon in the <...>/eclipse/plugins/com.ibm.cpp.core/icons directory of the form objName.gif for every format (objName = some_pattern) in the formats.dat file.

    • Contact Us