Is there any way to tell DOORS to use the current command prompt window as the interactive window when executing in batch mode?
For example, if I have hello.dxl which looks like
print("Hello world")
and Run.bat which looks like
"C:\Program Files\IBM\Rational\DOORS\9.6\bin\doors.exe" -u test -pass testPass -b hello.dxl -W
It currently opens a new window, prints "Hello World" and then closes the window (it closes it because of the -W). Is there any way to redirect this output to the command prompt window that was opened to run the batch file?
There is no console variant of doors.exe and as far as I know there is no possibility to give a sort of handle to a specific prompt window and use e.g. OLE Automation to print to this window, so, basically, no, it's not possible.
A workaround that we use for this requirement is to have a batch file which
generates the name to a temporary file ,
passes this file to DOORS as a parameter (using environment variables)
make DOORS/DXL cout to this file
after the DXL has finished, type the content of the temporary file in the calling batch and optionally delete it.
PS: according to https://www.ibm.com/mysupport/s/question/0D50z00006HIM4oCAH/doors-print-redirect-tutorial-for-print-cout-and-logfiles it apparently used to be possible to redirect STDOUT/STDERR to a specific file, but not in recent DOORS versions.
Related
In a batch file I can get the width of the console window using one of the examples here:
Windows console width in environment variable
#echo off
for /F "usebackq tokens=2* delims=: " %%W in (`mode con ^| findstr Columns`) do set CONSOLE_WIDTH=%%W
echo Console is %CONSOLE_WIDTH% characters wide
Similarly, I would like to know how to get the width of the parent shell's console when I run a VBscript from a Command Prompt. If I try running the above batch file from VBscript using:
CreateObject("WScript.Shell").Run "cmd /k FindWidth.bat"
A new console opens, and the width given by FindWidth.bat is for the new console window, not the console of the parent shell.
Using VBscript I can find the process ID of the parent shell using the following method: In a vbscript, how can i get the process id of the cmd.exe in which the vb script is running. Is there a way to do something similar to find its console column width? Maybe another method can be used since the process ID is known?
EDIT UPDATES:
I thank everyone for the comments. I'll try to add some more information of what I'm trying to accomplish. I have a kind of work around already but I was hoping for a slightly better solution.
The VBscript is run from a Command Prompt directly. Unfortunately, the VBscript is most likely run from wscript.exe because that is the default on normal Windows installations. But I still want to output error messages and other messages to the console and not to a popup window.
If I could guarantee it was run with cscript, there would be no problems. Restarting the VBscript with cscript starts a new process so any messages from the newly run csript VBscript go to a new console and not the original console.
I have a solution which works but it is clumsy because it uses a batch file wrapper with the same name as the .vbs but with a .bat extension instead of .vbs extension. All the batch script does is run the VBscript using cscript. It is mentioned in this topic: In vbscript, how do I run a batch file or command, with the environment of the current cmd prompt window?
I was hoping to find a way to get rid of the batch file wrapper but now I don't think it is possible.
I was trying another workaround which allows WScript to be used. Since the process ID of the console window can be obtained, a message can be sent to the original console window by first guaranteeing it is activated with:
objShell.AppActivate(ProcessID)
Then the script can immediately send a message to the original console with:
objShell.SendKeys ":: " & WindowMessage & "{enter}"
The trick is using "::" to make the message a comment that doesn't do anything. This works okay. One small problem is that it makes the console window use the comment for the last command buffer so if the user presses the up arrow or F3 etc, the comment is shown like it was a command they typed themselves. That is annoying but since it is just a comment, no errors are produced and it isn't much of a problem.
The part that is annoying is that the message appears on the same line as a normal command and doesn't look like a proper cscript sent message. The reason I wanted the width of the console is to format the message by buffering it with the proper number of spaces so that it looks identical to a message that would have been sent from cscript. Then it would look like real stdout output except for the ":: " at the start of the message.
The script could just read the default setting for the command prompt but that will not format it correctly in a lot of cases.
If I could find a way to go to a new line with SendKeys and send the message before the PROMPT appears, that would do the same thing. Is there a character that could be sent which would start a new line before the PROMPT appears??
Is there a way of using VBscript to inject a text message into the stdout of a specific console window. Being that the process ID is known of the console that should get the stdout, is it possible for the wscript VBscript to run another batch script or another program silently which could use the Process ID to inject a message into the stdout of the original console window.
Ultimately, all I wanted was to have the VBscript file be run directly in a Command Prompt that can output messages to that same console. But to do that properly seems to require the user type "cscript scriptname.vbs arguments" instead of just "scriptname arguments" which is how it should be possible but apparently isn't! Using a batch file wrapper is another option that kind of tricks the user into running a different batch file instead of the VBscript file directly. I guess I would need to redo the script in a real computer language instead of a scripting language to make it work properly. I really don't understand why this is so difficult to accomplish with VBscript when it seems like it should be trivial.
It is a bit annoying that Windows sets VBscript to use WScript by default when WScript doesn't allow any console output at all. But CSCript can do both Windows popups and console output. Why even have WScript vs CScript distinction at all when it seems like everything can be done with CScript alone?
I'm writing myself a GUI utility for use in a CMD window to navigate between folders,
rather in the style of the old Norton Change Directory utility for DOS.
When run, the app pops up a folder tree to allow the user to select a folder to which
to navigate and then closes and returns to the CMD prompt. At the moment, the way it
works is that it is run as the first command in a "main" batch file. It writes a secondary batch
file, in my app's folder under AppData, containing the commands to change drive and
directory to the folder the user selected, and the main batch file then invokes this
second batch file using CALL.
It works fine, but this way of actually changing the CMD window's current directory
strikes me as inelegant both from the point of view of needing to be run from a batch file
(so that the user's selection can be acted upon after my app has closed) and of
needing the secondary batch file to do the actual navigation.
So, my question is, how can my app send the instructions to the instance of CMD
that owns the window in which the app is run to the folder the user selected? I've tried doing a ShellExecute
of "CMD /K ..." but although that does indeed navigate to the
selected folder, it does so in a new CMD window, not the one my app is run in. The
conceptual gap I have is how to get the current CMD to act on my app's instructions
after my app has terminated.
Fwiw, I thought of trying to write the user's folder selection into an environment variable in the CMD window's environment for the CMD processor to
act upon from there, but this seems to require that the CMD window be opened via "Run as Administrator", which I definitely don't want.
Your program cannot influence the environment variables of the command interpreter because they're separate processes. Your program cannot change the directory of the command interpreter directly, either, because, again, they're separate processes.
You need to use a batch file because the command interpreter executes batch files internally. Since it's all the same process, the batch file has the power to change the current directory, and for that change to remain in effect after the batch file finishes running.
Therefore, you need some way for your interactive program to communicate the directory selection back to the batch file so that it can act on it.
Instead of writing the instructions to another batch file, you could write the result to standard output. Have the batch file capture that output into a variable, and then execute cd on that variable. The batch code would look something like this:
for /f "tokens=*" %%a in ('[select_dir.exe]') do (
set DIRSELECTION=%%a
)
cd /d %DIRSELECTION%
Your Delphi code would look like this:
writeln(selected_dir);
To allow that command to work, you'll need to make sure your program is marked as a console program, as with {$APPTYPE CONSOLE}. If it's not, then the batch file won't receive any output, and probably won't even wait for your program to finish running before proceeding. It's OK for a console program to display a TForm, just like a GUI program.
I'm running a command through the Windows shell- an existing command window (cmd.exe). When I execute the command, the window closes, even though it's a freestanding window not tied to the command.
How can I keep the window open to see the output?
You can't simply start a child cmd session because it'll share same window and if your custom tool actively closes its window (I wonder why) then it'll close your console and output will disappear.
There isn't much you can do if a program want to close console window but you can at least save its output to a file (to be inspected later with type). If you're working with that console and you don't want to close it then you can use start cmd to execute it in a new console window. Like this:
start cmd /c tool -args ^> output.txt
tool output will be available in output.txt after it finished.
It appears that the executable is closing the command window. Here is what you could try, may work. open a command shell. In the shell issue "cmd" and open another command shell. Run your executable in the newly opened command shell. You nested cmd will be exited, but you may still be able to see some of the output of your executable.
I have another bat file that I'm running, and once in the command prompt that bat file creates, I want to run another command in that window.
Here's what I have so far:
call C:\Batch\MyBatFile.bat (this creates the new command prompt that I want to use)
C:\Program\MyProgram.exe
However, the second line is being run in the original window, instead of the new command prompt. I tried using start C:\Program\MyProgram.exe, but that just ran in a 3rd new window instead.
If it's relevant, the first line is just setting a few environment variables that I need access to and MyProgram is a visual studio 2010 project. Technically, I might be able to modify that bat to run the command, but I'd rather avoid that solution as that bat file isn't owned by me (and thus whenever it's updated I'd have to update mine as well).
Thanks in advance.
You could try to inject your program.exe into cmd created by batfile.bat by redirecting it's input stream and then sending it a command, eg. echo C:\Program\MyProgram.exe | C:\Batch\MyBatFile.bat. This assumes that batch really just sets bunch of variables and does not use commands which reset/consume input stream.
Please note that if redirected/piped this way new command window will not stay open It will maybe :-) just execute your command and then close/exit.
Create a CMD script to run both of the commands that you have shown in the question. Maybe call it RunMyProgram.cmd. The contents are just the two lines that you have:
REM Source the environment variables.
REM Any new command prompt window that is opened can be ignored
CALL C:\Batch\MyBatFile.bat
C:\Program\MyProgram.exe
If what you have stated in the comments to your question is accurate regarding MyBatFile.bat setting up the environment variables and then starting a new window, then you should be able to make use of those environment variables after MyBatFile.bat exits.
If running RunMyProgram.cmd from a command prompt still has MyProgram.exe giving the error when the environment variable is not set, or if MyProgram.exe doesn't even start to run until you close the new window that popped up, then we need to see the exact commands that MyBatFile.bat is executing.
I run batch files and they exit immediately. I dont want that to happen so that i can see my output. Can someone tell me how to make this happen ?
I use windows 7.
Put this on the very last line of the Batch:
cmd /k
Adding pause is a good answer. Here are some other ways as well..
Rather than double-clicking on them to execute you can run from a command line:
Press the windows key + r (this opens the "run" window)
Type: cmd into the text input and press enter (or click ok)
Change to the directory that contains the batch file, e.g: cd c:\scripts\foo
Execute the batch file by typing it's name and pressing enter, e.g: somename.bat
If there is a lot of output and it scrolls off the screen you can direct the output to a text file instead like so:
somename.bat > output_filename.txt
Then you can open the 'output_filename.txt' file in any text editor to view/search all of the output. This is better than pause when there more output than what is available in the scrollback.
Add the pause command at the end of your batch file. This waits for you to key something in.
(The nice thing is that if you're running the batch file from a non-interactive process, such as a automated build system or scheduled task, the pause is simply skipped.)
The help message for pause is:
C:\>help pause
Suspends processing of a batch program and displays the message
Press any key to continue . . .
If there is lots of output and you can't scroll far enough back, adjust the screen buffer height of the command window. This can be done via right-click on the c:\ icon go to properties -> layout: