Stephen Crawley's blog

The notion of a "current directory" allows users (and applications) to use shorter relative pathnames for objects in the file system. This concept is common to all modern operating systems, and also to the classic Java runtime system.

However, there are important differences between the UNIX/Linux and classic Java models of the "current directory".

1. The UNIX/Linux 'current directory' is part of the state of a process. Changing one processes current dierectory has no effect on the current directory of other processes. By contrast, the classic Java "current directory" is the value of a System property, and is shared by all entities in the VM.
   

A typical UNIX command sets a return code when it completes to say whether it succeeded or failed. A C/C++ application calls the 'exit' function, and a Java application calls System.exit.

UNIX shells and other scripting languages rely on return codes at a pretty fundamental level. So if we want to implement a UNIX-like shell, we need to have a way to get return codes from JNode commands.

It appears that calling System.exit() from a JNode command should cause a VMExit exception to be thrown, holding the status value from the exit(int) call. I can catch this exception in the shell and snaffle the status value as a return code. However, there are some problems:

I've made significant progress on the bjorne shell. It can tokenize and parse most of the grammar (apart "here" documents), and it can execute shell variable assignments and simple commands with simple '$' expansions.

I'm now running into a number of issues in the nexus between the shell and invoked commands. These include how to support return codes, numbered file descriptors, PIDs/job control, environment variables and the current directory. I'll talk about these in future blog entries.

I've started working on a new command line / script interpretter for JNode. My intention is that the "bjorne" interpretter should be 100% compatible with the classic UNIX Bourne shell in syntax, and as compatible as is possible with its semantics. (I'm using the shell specification in IEEE Std 1003.1, 2004 Edition as my guide.)

I've also prototyped some refactoring of the existing "org.jnode.shell" classes to make the CommandShell and the CommandLine API (and hence JNode commands) independent of the command interpretter chosen by the user.