above (18.8, 18.9), adjusted like this: BufferedReader pOut= new BufferedReader( new InputStreamReader(p.getInputStream())); try { String s = pOut.readLine(); while (s != null) { System.out.println(s); s = pOut.readLine(); } } catch (IOException e) { } Another possibility is to read chunks of whatever length as they come in: ... p = r.exec(cmd); InputStream is = p.getInputStream(); int len; byte buf[] = new byte[1000]; try { while( (len = is.

Use Runtime.getRuntime().exec( myCommandString ) where myCommandString is something like "/full/pathname/command". An applet will need to be signed in order to allow this. If the pathname contains spaces, e.g. "c:\program files\windows\notepad", then enclose it in quotes within the quoted string. Or pre-tokenize them into elements of an array and call exec(String[] cmd) instead of exec(String cmd). From JDK1.3 there are two new overloaded Runtime.exec() methods.

Unix and some other systems provide a popen() routine, which sets up a stdio stream on a pipe connected to the process running a command, so that the output can be read (or the input supplied).

From: tim@mks.com (Timothy D. Prime) Subject: Re: hide the text of expect's send command? Date: 29 Mar 1996 15:41:02 GMT In article <khughesDoy1yH.5zo@netcom.com>, Kirby Hughes <khughes@netcom.com> wrote: > I don't want to see (on the screen) the text sent by a "send" command. Is > there a way to hide it? "log_user 0" works for text coming back to me, but > doesn't (seem to) work for sending..

If you are running programs from a command prompt (by typing commands into a terminal emulator window or an MS-DOS box), these things can be done easily. If you have ever used GNU/Linux, Unix, or MS-DOS, you may have captured the output of a program by redirecting it to a file, like this: foo >bar The > operator redirects foo's standard output (which would normally appear on-screen) into a file named bar. If bar exists already, its contents are replaced.

Package names are guaranteed uniqueness by using the Internet domain name in reverse order: com.javasoft.jag - the "com" or "edu" (etc.) part used to be in upper case, but now lower case is the recommendation. Class and interface names are descriptive nouns, with the first letter of each word capitalized: PolarCoords. Interfaces are often called "something-able", e.g. "Observable", "Runnable", "Sortable".

JDK 1.2 has System.setProperty( "property", "new value" ); Until then, you can get all the properties, and set just the one you want with code like this: System.getProperties().put("property", "new value" );

There are several ways. The most straightforward is: String myString = numString.trim(); int i = Integer.parseInt(myString); long l = Long.parseLong(myString) or String myString = numString.trim(); i = Integer.parseInt(myString,myIntRadix); Note 1: There is a gotcha with parseInt - it will throw a NumberFormatException for String values in the range "80000000" to "ffffffff". You might expect it to interpret them as negative, but it does not. The values have to be "-80000000" .

Try any of these: String s = String.valueOf(i); or String s = Integer.toString(i); or String s = Integer.toString(i, radix); or // briefer but may result in extra object allocation. String s = "" + i; Note: There are similar classes for Double, Float, Long, etc.

Use bytes, shorts, chars, ints or longs if you need to manipulate no more than 64 bits at once. Use ~ for NOT, & for AND, | for OR, and ^ for XOR. Beware that the precedence for & | and ^ is not intuitive; they have lower precedence than == and !=, so you must write: if ((a & 1) == 1) rather than: if (a & 1 == 1) You can also shift bits with the <<, >> and >>> operators; >> is a signed shift and >>> is an unsigned shift.

Look at the code below, submitted by expert programmer John Dumas. It uses serialization to write an object into a byte array, and reads it back to reconstitute a fresh copy. This is a clever hack! import java.io.ByteArrayOutputStream; import java.io.ByteArrayInputStream; import java.io.ObjectOutputStream; import java.io.

To save the output of a command that you have executed you must first open a DOS command prompt. At the command prompt type "[EXECUTABLE] > [DESTINATION FILE]" and press enter. The string "[EXECUTABLE]" is the name of the command which you wish to save the output of. The string "[DESTINATION]" is the name of the file in which you wish to store the output. Once you have pressed enter, you have saved the output to a file with the name in which you specifed in the destination.

Code like this seems to show that the calls don't work! String s = " hello "; s.trim(); s.toUpperCase(); Note again that Strings are immutable. This means that once a String has been initialized, its contents won't change. In the code above, the method calls return a different String with the desired alterations. But this new String is not assigned to anything, so the results are discarded. To see the changes, assign the results of the method call to the original String or to another String.

You can print the hex equivalent of an int with: int i = 0xf1; System.out.println("i is hex " + Integer.toHexString(i) );

Simple answer: use a "callback". Make the parameter an interface and pass an argument instance that implements that interface. public interface CallShow { public void Show( ); } public class ShowOff implements CallShow { public void Show( ) { .... } public class ShowOff2 implements CallShow { public void Show( ) { .... } public class UseShow { CallShow savecallthis; UseShow( CallShow withthis ) { savecallthis = withthis; } void ReadyToShow( ) { savecallthis.

This solution works on Unix platforms using either JDK 1.0.2, or JDK 1.1. The trick is to use an array of Strings for the command line: String[] command = {"/bin/sh", "-c", "/bin/ls > out.dat"}; If you don't do this, and simply use a single string, the shell will see the -c and /bin/ls and ignore everything else after that. It only expects a single argument after the -c. import java.io.*; import java.util.

The reason is that many of the DOS commands are not individual programs, but merely "functions" of command.com. There is no DIR.EXE or COPY.EXE for example. Instead, one executes the command processor (shell) explicitly with a request to perform the built-in command, like so: Runtime.getRuntime().exec("command.com /c dir") for example. On NT, the command interpreter is "cmd.exe", so the statement would be Runtime.getRuntime().

This code is from the 1.0 AWT, and the programmer was probably pretty skilled. public synchronized void layout() { LayoutManager layoutMgr = this.layoutMgr; if (layoutMgr != null) { layoutMgr.layoutContainer(this); } } The code makes a local copy of a global variable for one or both of two reasons. The first reason is that accessing local variables can be faster than accessing (non final) member variables. It's good for loops or where there are many references in the source.

a & b" takes two boolean operands, or two integer operands. It always evaluates both operands. For booleans, it ANDs both operands together producing a boolean result. For integer types, it bitwise ANDs both operands together, producing a result that is the promoted type of the operands (i.e. long, or int). "|" is the corresponding bitwise OR operation. "^" is the corresponding bitwise XOR operation. a && b" is a "conditional AND" which only takes boolean operands.

The only way in pure Java to create globally unique ids is to set up a server, accessible by all interested parties, which supplies the ids. There are classes in Java which may supply 'probably' unique ids, with varying levels of reliability --- but a dual processor machine with two JVMs running could easily generate duplicate ids. Note that a global server issuing a token (and periodic "are you still using it" messages) is a pretty good way to do cooperative file locking too.