REALbasic Shells Are Not Unix Shells

· Mar 14, 07:09 AM

First-time users of REALbasic Shell objects are often confused by an aspect of its behavior. Consider the following code.

dim s as new Shell
s.Execute "cd foo"
s.Execute "ls"
Print s.Result

If you are drawing on your experience using Unix shells, you probably expect the output to be the contents of foo. But it is not; instead, it will be the contents of some other directory. In my tests on Mac OS, for GUI applications, that directory is /, and for console applications it is ~.

This is not a bug; the Shell object is behaving as designed, and the design is correct. In fact, Shell is probably misnamed. A better name might be "Subprocess", like that of the corresponding object in Python. For this better describes the functionality of the Shell class.

Setting the Shell.Mode property determines the interaction of the subprocess with the parent: blocking or non-blocking, and whether or not it accepts input from the parent. But each invocation of Shell.Execute creates and executes a new subprocess.

---

Comment

  1. I got bitten by this quite recently. The explanation was that each shell.execute operation is complete, in itself, and has no dependency on previous shell.execute operations. As a result, in order to get the “desired” result in the example code, it is necessary to string together multiple shell commands in a single string with command delimiters (commas, semicolons, ???) between them.

    — Jim Wagner · May 14, 11:22 AM · #

  2. You use semicolons.

    — charles · May 14, 11:35 AM · #

Commenting is closed for this article.