Menu
▾
▴
#301 Interactions commands
Possibly add some more O/S like interaction commands:
pwd - print working directory
cd [path] - change working directory to new path
shell [path] - open a shell window to either the
working directory, or an optional path
Some other possibilities:
javac file - compile java file
exec path - run an OS command
Logged In: YES
user_id=1075744
The problem with "cd [path]" is that Java's "user.dir"
property is read-only. That's the problem we have been
having all along and the reason why we have to restart the
Interactions Pane every time the working directory is
changed or a project is opened or closed.
We *could* implement "cd", but it would trigger a reset of
the Interactions Pane.
We just have to accept that we'll
1) EITHER have easy access to Java classes, fields, methods,
etc.
2) OR have an easy way to change the current directory
but never both at the same time. What this suggests is that
we could write a simple shell console that allows those
commands above, but doesn't do Java. When you run a program
from the GUI or by typing "javac", the console switches
modes and becomes our current Interactions Pane. When the
program ends, the console changes back to a shell console.
I'm not sure how useful this is, though.
"pwd" can easily be emulated already with
System.getProperty("user.dir"), but it could be done, of
course. "javac" is relatively unproblematic too.
"shell [path]" and "exec path" are difficult because shell
windows and OS commands are platform-specific. The shell
executable to invoke might have to be configured by the user
or in some other way auto-detected. But it's possible, of
course.
Logged In: NO
It would be useful to have some shell functionality, e.g, redirection and piping.
All popular OSs (Windows, OS X, Linux) support these abstractions with <, >,
and |. When teaching novices, this provides a simple way for programs to
interact with files and other programs. The Interaction Pane could be a gentle
introduction to using a shell. I have no idea how feasible this would be, but it's a
thought...
Logged In: YES
user_id=1075744
Redirection and piping should not be too hard to implement.
We already support reading from System.in by showing a small
frame in the Interactions pane that allows the user to enter
text.
Piping into a program would just deactivate that feature
(perhaps re-enable it when the input stream or file ends)
and read from the specified stream or file. Reading from a
file would actually be easier than what we have to do right now.
The syntax could look like this:
java MyClass < somefile.txt
We also need to capture the console output of a program and
display it in the Interactions Pane. Saving it additionally
into another stream or file should not be difficult.
Therefore, we could have this syntax:
java MyClass > output.txt
java MyClass >> append.txt
If we generalize this to streams, then we get piping from
one program to another:
java MyOutputClass | java MyInputClass
We could theoretically even go beyond that and support
piping for individual statement entered in the Interactons
Pane, e.g.
System.out.println("foo") > output.txt
Of course, this introduces ambiguities with the Java syntax.
What should this line do:
5 > 3
Should it return true (current behavior) or pipe to a file
named 3?
We could try to find a non-ambiguous syntax for piping with
individual statements, but that notation would be less
useful to teach shell functionality, so I propose to first
add piping and redirection only to the case when the "java
MyClass" form is used.
Logged In: NO
> We already support reading from System.in by showing a small
> frame in the Interactions pane that allows the user to enter
> text.
Yes, I find the current implementation of System.in to
be very elegant.
> Piping into a program would just deactivate that feature
> (perhaps re-enable it when the input stream or file ends)
> and read from the specified stream or file. Reading from a
> file would actually be easier than what we have to do right
> now.
>
> The syntax could look like this:
>
> java MyClass < somefile.txt
>
> We also need to capture the console output of a program and
> display it in the Interactions Pane. Saving it additionally
> into another stream or file should not be difficult.
>
> Therefore, we could have this syntax:
>
> java MyClass > output.txt
> java MyClass >> append.txt
>
> If we generalize this to streams, then we get piping from
> one program to another:
>
> java MyOutputClass | java MyInputClass
This sounds perfect for what I would use it for in my class.
> We could theoretically even go beyond that and support
> piping for individual statement entered in the Interactons
> Pane, e.g.
>
> System.out.println("foo") > output.txt
>
> Of course, this introduces ambiguities with the Java syntax.
> What should this line do:
>
> 5 > 3
>
> Should it return true (current behavior) or pipe to a file
> named 3?
>
> We could try to find a non-ambiguous syntax for piping with
> individual statements, but that notation would be less
> useful to teach shell functionality, so I propose to first
> add piping and redirection only to the case when the "java
> MyClass" form is used.
That's definitely an interesting idea. Although for me,
it is the shell-like functionality that is most useful.
Thanks for taking the time to think about these issues!
-googmeister@gmail.com
We now have another Interactions command, in addition to the "java MyClass" command:
applet MyApplet
will run an applet viewer with MyApplet in it.