Apache OpenOffice Community Forum

I am having a problem using the shell function to run a windows command - I want to run the dir command and send the output to a text file for further processing. I can get shell to display the calculator as an example but I cannot get it to produce a command prompt window and hence run the dir command.

I can fire up the Windows calculator using this code:
Shell("c:\windows\system32\calc.exe",2)

But this almost identical code does NOT bring up a Command Prompt window:
Shell("C:\WINDOWS\system32\cmd.exe",2)

In each case, the code between the quotes does work fine when entered in Start, Run

Please does anyone have any idea what is going on here?

(As background, what I am trying to execute is something like this, but without success:
Shell("C:\WINDOWS\system32\cmd.exe",2,"dir I:\Backups\Backup*.odt > C:\tempdirtext.txt",true)
which I hope will send the output from the dir command to a temporary text file for further processing.
But I am stuck on the very first step.)
OS is Windows XP Media Edition,, OOo v3.0.0

You don't need a terminal (cmd.exe) to run Basic's shell command.

Sorry for picking up this issue again after half a year, but obviously it is not solved and I am stuck in the same problem. I have no clue why it is like that, but what the original poster describes is a reproducable behaviour on MS Windows Systems across OOo versions. (I use 2.4.2 and 3.1).

Villeroy wrote:You don't need a terminal (cmd.exe) to run Basic's shell command.

This might be right in most cases, but for the described constellation to capture the output of the dir command it does not apply. Because in contrary to the Linux ls dir is not an executable on its own, but an internal command of the shell (cmd.exe). The plausability test that hopefully everyone is doing before complaining that the Shell() command in a macro is not working is to run the same statement in the Startmenu - Run - Command

Here is some macro code that I used for testing the Shell BASIC command (on Windows 2000):
The general observation is that the MsgBox is not waiting until the process started by Shell is completed, but shows up directly -- though in the background, because the 1 as 2.Parameter places the window that is started with Shell into the foreground.

• Notepad shows up (it requires not the full path specification as it is in the search path)
• cmd.exe of the 2. Shell command doesn't show
• The StartProc.exe from the last Shell command is started successfully. StartProc is a Win32 API C program that I compiled with MinGW. It shows a Message Box with the current working directory and the command line parameters. These two strings are passed to the Win32 API CreateProcess to create a child process. In my case the child process is the famous black window of cmd.exe

What's so special about cmd.exe? From a low level point of view it contains the the same machine code instructions to build the PE header with the startup code for executables. I even gave it a try and copied cmd.exe to another location with another name C:\bin\runcmd.exe and used that as parameter for Shell(): same problem as with the original cmd.exe. Nothing can be seen.

Interestingly enough zip.exe or other commands that normally need the stdout console for their user interaction work if called inside the Shell command. This was my original aim, export several spreadsheets and pack them into a zip archive. You won't see any output of the zip command, but at least the archive file is created. But in most cases not as it should be done. For me the working
directory was always OOO_INSTALL_PATH\program, which is not the directory from that I want to zip the files. Two ways to get around this restriction:

• Use full path names in the zip command line parameters (makes the zip archive useless)
• change to the desired directoy before executing the zip.exe

Okay, I can do a: cd \this\dir && zip test.zip but this will only work if I have a command interpreter to parse this construct, hence I am bounced back on cmd.exe as interpreter ... and it won't start.
The solution can't be that I have to write my own command interpreter just because the official interpreter will not be executed by OpenOffice.
Why do I need to "wrap" cmd.exe into another launcher application to hide it from OpenOffice?
As far as I saw from other threads, this problem is specific to Windows. In Linux /bin/bash or
$SHELL do just work like any other executable.

Don't use Basic if you want control over threading. OOo's Basic is not a programming language. It's hardly more than a convenience tool for API calls to this particular office suite.

My post was not about threading and asynchronous behaviour, but about the strange treatment of cmd.exe in the Shell BASIC command. I just added this because I had a hard time to collect information on the behaviour of Shell and decided to leave it here for the sake of completeness if someone else will look at this thread in the future.
But in the meanwhile I found a solution for my original problem with using the command line zip.exe to archive some saved spreadsheets using the SystemShellExecute Service:
This does exactly the same as if I run
cmd.exe /k "cd \temp && zip test.zip HKCR-ooo.reg"
from the Startmenu - Run. It changes into the directory C:\temp and creates a new file test.zip with HKCR-ooo.reg as its content. Unfortunately the API reference is not very helpful about the last parameter:
http://api.openoffice.org/docs/common/r ... ecute.html

Specifies different flags to control the execution of this method, for example, avoid showing system error messages, in case of failures, etc.

Maybe one of the flags tells the parent process to wait until the child process is completed?
At least I figured out that for executables in the PATH the full path to the executable file is not required. So I give it a go and suggest some code that should work for the request of the OP:

Since all ODF is zipped XML, zipping ODF docs will not save disk space.
You may find a zipper in the office-API, may be http://api.openoffice.org/docs/common/r ... le-ix.html

Thanks Villeroy for pointing out that there is something like a zip library in the API.
I thought in this direction when my direct attempt with the Shell() command was not working. "There must be a way withouth the need to use an external program. After all OpenOffice uses the zip algorithm every time when opening or saving a file!" And I actually had a look at the com.sun.star.packages services just yesterday. But it looks way to complicated and I found more pointers for reading from the zip archive format, but hardly some that looked like they can be used for writing.

As far as I understood, I will have to open each file that should go into the zip archive as a I/O stream, convert this somehow into a package stream and finally add this package stream to the package archive. Seems like 4 or 6 hours of investigation with a lot of potentially wrong tracks, but without the guarantee that it is really working at the end. Maybe it exceeds the capabilities of BASIC!?

Based on these considerations I'd rather stick to the external program and pay a performance penalty for starting a new process (okay 2 processes, the shell and the zip child process). On the other hand the external zip is surely more efficient when opening the files that should be packed into the archive than my BASIC commands that try to control the I/O streams.

And it seems that I was unclear in my last post: The "saved spreadsheets" are spreadsheets that are exported into csv format. I need to attach them to a mail, so I prefer to wrap them into a zip archive to preserve the timestamps. As csv files are plain text with quite a lot of redundancy they compress nicely.

Never the less, can we focus on the original question: What is it, what the Shell command doesn't like about the cmd.exe? And why is it refusing to execute cmd.exe, although all other executable files are started?

I have a similar (related?) problem in OSX.

I had to find out, that neither the 'Shell' command, nor 'com.sun.star.system.SystemShellExecute' work: This does not throw an error (it does, if I enter a wrong command, e.g. "/usr/bin/thisappdoesntexist" or "unzip" without the path).

It just doesn't do anything, and returns "0" (no errors) regardless of anything (i.e. even if the parameters passed are wrong).

Let us return to the original problem:

johnoflet wrote:As background, what I am trying to execute is something like this, but without success:
Shell("C:\WINDOWS\system32\cmd.exe",2,"dir I:\Backups\Backup*.odt > C:\tempdirtext.txt",true)

You don't need to open a Command prompt window.

1 - Write a simple batch file containing the MS-DOS command (you remember batch files ?).
My batch file listOdt.bat contains one line : 2 - run the batch file from Basic like this: Note the ConvertToURL() for the command address. It is necessary if the path contains spaces or national characters. If you don't do this Basic Shell does not work correctly. API SystemShellExecute does work with a system address.

Of course you can create the batch file with Basic.
______
Bernard