[sharing] Java shell access
Hi fellow Maxers,
As a somewhat inferior alternative to good 3rd party externals (aka.shell, shell, DOSHack)...
Here's a simple Max java class for shell access - works on Mac and should/might also work on Windows (although I've mostly used it on Mac, and of course DOS expects some different commands). Runs in its own Java thread, so repetitive tasks such as pinging run nicely alongside Max processes.
Classes, maxpatch, and sample bash script attached.
best,
Zachary
thanks, a good shell alternative for windows user (tested on max5)
but doesn't pass error to outlet.
thnaks Zachary,
nice touch with the STDIN communication example
im still getting a crash with curl for a certain URL.
only if outlet is connected
other then that everything is fine.
Hi Yair,
On my machine (early 2011 MBP, Max5) It doesn't crash if I send the output to a message box, but it does crash with print and capture...
best,
Zachary
Nice one Zachary!
I used it instead of [shell] on a patch that sends data to pachube. The thing is, it does not work in Windows.
If I send something like this ..
curl --request PUT --header X-PachubeApiKey:[there should be an API key here] --data 0.00,0.00,0.00 http://www.pachube.com/api/ [there should be a feed number here].csv
I get an error saying: java.io.IOException: Cannot run program "curl": CreateProcess error=2, The system cannot find the file specified
The same with trying to send "date".
I am guessing it is how [mxj shellAccess] reacts in Windows to those commands. The thing is I don't know if it is either from [mxj shellAccess] or from not having installed (properly) cURL.
Can you tell me a proper message I should send to [mxj shellAccess] in Windows so I can get some info out of it so I would know it is working?
Thanks ygreq,
I'll check that out on Windows and get back to you soon (in a day or so, hopefully).
best,
Zachary
Thank you Zachary!
I'll be waiting impatiently! :D
Hi ygreq,
I worked on this a bit today. Looks like it may have always been somewhat broken on Windows. I've made a few changes, now different classes used for Mac or Windows. Only tried on XP (sorry). Download this, try it, and see if it works.
For date on Windows, you should send the message 'date /T' so that the system doesn't expect you to enter a new date (this is slightly different from Mac behavior). I didn't have time to try curl. Let me know how it goes.
You could also use the Windows-only DOSHack object...
best,
Zachary
Hey Zachary!
Thank you so much for taking your time to look into this. I just tried your last version and it works on Win7. At least the example with the date. As for cURL, I probably don't know how to install it. I tried DOSHack as well. :(
I will copy the patch for anyone wanting to use it on OSX or willing to help use it on Windows 7.
based on nnim's code (https://cycling74.com/tools/pachube-tools/)
(see also: http://community.pachube.com/tutorials#max)
All the best,
ygreq
Hi Zachary!
I abandoned the idea of using a PC so I bought a really cheap mac mini. I installed everything and I let it run for a day or so. It keeps pushing data every 2 seconds to pachube via cURL message. It works fine for more than a day. But after that it just starts to output the following message:
"shellAccess: java.io.IOException: Too many open files"
Now with this error present, even if I send the message "date", it still outputs the same error.
I also tried to use [shell] and almost the same thing happend. After a day [shell] does not output anything anymore.
Do you know what that error means? What open files is it talking about?
I have a PPC Mac Mini with OSX 10.5.8 installed on it.
Thank you,
ygreq
By the way, I found an interesting forum post in stackoverflow, but it's foreign language for me.
I *think* this might be because of the way I was handling BufferedReader and OutputStreamWriter, but we'll see. I've updated the mxj external for Mac and Win.
There's some streamlining in here that should help you. Now when the process completes you get a bang out of the right outlet. This way, if you're doing something periodically, and the previous process has not completed, you can choose to either send 'destroy' and move on to the next process, or wait until you get a bang.
best,
Zachary
excellent Zachary, thanks so much.
Thank you, Zachary.
I just looked at it and I think there is something wrong with the mxj object. There is no right outlet and it gives me this output on the max windows:
shellAccess by Zachary Seldess. Build Jan 1 2011.
Copyright © 2011 King Abdullah University of Science and Technology. Some Rights Reserved.
shellAccess by Zachary Seldess. Build Jan 1 2011.
Copyright © 2011 King Abdullah University of Science and Technology. Some Rights Reserved.
mxj: jpatchline_new: index out of range
jpatchline_plugin: box missing outlet number 2
mxj: jpatchline_new: index out of range
jpatchline_plugin: box missing outlet number 2
shellAccess by Zachary Seldess. Build Jan 1 2011.
Copyright © 2011 King Abdullah University of Science and Technology. Some Rights Reserved.
mxj: jpatchline_new: index out of range
jpatchline_plugin: box missing outlet number 2
By the way, may I ask if you study at KAUST? I searched the web. Looking good!!
All the best,
ygreq
PS: I copied the files on Max5/Cycling '74/java/classes. I am guessing that is where they should be, right?
PS2: Does everything work ok for you, Yair?
Hi ygreg,
You almost certainly have an older version in your searchpath somewhere. Check /patches, etc.
Once you've cleaned out the old one, you can put the new mxj classes anywhere you want in the searchpath: /Java/..., /patches...
best,
Zachary
PS - Re KAUST, I run/do research/sonify on the audio systems at the KAUST Visualization Lab. Here's a link. Need to update the site to include more useful details on the audio capabilities (which are significant...):
http://vis.kaust.edu.sa
Hi guys,
I made the external cross-platform (which is basically the whole point in using Java for something like this). In the process, I did discover a problem with the Windows implementation that I haven't fully solved yet.
-If you run an unending process on Windows via shellAccess, such as 'ping localhost', and then you send 'destroy', it doesn't actually kill the process, but only kills the parent process (cmd.exe). So you'll need to then send another Windows-specific command to kill that process (tskill, taskkill, etc.).
Anyways, here's the newest.
best,
Zachary
Hey Zachary,
On my macbook pro (2.8GHz Intel Core2Duo, 8GB 1067MHz DDR3 with OSX 10.7.2) everything works ok (don't know if it will give any more "too many files open" errors yet).
On my mac mini (PowerPC G4 1.25GHz, 1GB DDR RAM, with OSX 10.5.8), I get this error:
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:676)
at com.cycling74.max.MXJClassLoaderImpl.doLoadClass(MXJClassLoaderImpl.java:119)
at com.cycling74.max.MXJClassLoader.loadClazz(MXJClassLoader.java:88)
Could not load class 'shellAccess'
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:676)
at com.cycling74.max.MXJClassLoaderImpl.doLoadClass(MXJClassLoaderImpl.java:119)
at com.cycling74.max.MXJClassLoader.loadClazz(MXJClassLoader.java:88)
Could not load class 'shellAccess'
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:676)
at com.cycling74.max.MXJClassLoaderImpl.doLoadClass(MXJClassLoaderImpl.java:119)
at com.cycling74.max.MXJClassLoader.loadClazz(MXJClassLoader.java:88)
Could not load class 'shellAccess'
It seems to be something related to the java machine. It did't give these errors with old version of the files. I double checked.
Any ideas?
Thank you,
ygreq
PS: Thank you so much for the link :) Always good to find about places like these!!
Sounds like it may be because I compiled it with Java 1.5.0. Your machine probably has 1.4.2
Try to recompile it on your Mac Mini:
1. open the helpfile
2. click viewsource
3. go to Java-->Open Compile Window (cmd-k)
4. click the Compile button
In the Compiler Command window, what version does it list?
best,
Zachary
When I try to use the latest versions of your files, the [mxj shellAccess] object is in read and clicking "viewsource" does not work.
If I put the older files and follow your steps, clicking "viewsource" works of course and I get this in the Compiler Command: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javac
All the best,
ygreq
PS: The last version that works is the one that you made before creating the right output.
You copied it on the site where you commented the following:
<
I worked on this a bit today. Looks like it may have always been somewhat broken on Windows. I've made a few changes, now different classes used for Mac or Windows. Only tried on XP (sorry). Download this, try it, and see if it works.
For date on Windows, you should send the message 'date /T' so that the system doesn't expect you to enter a new date (this is slightly different from Mac behavior). I didn't have time to try curl. Let me know how it goes.
You could also use the Windows-only DOSHack object...
best,
Zachary>>
1. instantiate [mxj help quickie]
2. send it the viewsource message
3. go to File --> Open --> load newest shellAccess.java file
4. follow the steps from above
It worked!!!!!! :D
Thank you so much, Zachary!
I will let the the server run for a few days! I will let everyone know about the outcome.
All the best,
ygreq
Hey Zachary,
I am writing you this because maybe it is related to the java machine. There is a possibility that it is related to max runtime and the OSX, of course.
A strange happened! Twice. After leaving my patch open for a few days, it gets stuck. Max Runtime stops responding. If I try to force quit I can not. On "Force Quit Applications" window I can see the Max Runtime App running (there is no sign saying that it is blocked though) but it is present in the dock asking me to force quit it. I checked the Activity Monitor and I cannot find it there.
Any ideas?
Thank you,
ygreq
PS: The only option to quit Max Runtime is to restart the system.
Hi ygreq,
At this point, considering the same behavior is happening with [shell] and my Java object, you'd need to also consider what you are doing with the objects as a possible source of the problem (although the other scenarios you list are entirely possible). Can you post a patch showing us as close to exactly what you're doing as possible?
best,
Zachary
Hey Zachary,
With [shell] as with earlier versions of [shellAccess], the mentioned objects just stopped working after a few hours (the "too many open files" error). Now the whole patch stops working and I have to reset the system (not restart as I said earlier; I have to manually turn off the mac by keeping the power button pushed for a few seconds and start it afterwards as it doesn't restart by itself) in order to run again for another couple of days.
You can find [mxj shellAccess] in the [pachube] patcher.
Thank you,
ygreq
PS: I am thinking of testing it on my macbook as well (let it run for a few days to see what happens). Unfortunately I work on that one so I don't know when that is going to happen.
Hey Zachary,
I think I just found out the problem. Don't know how to fix it though yet. Any thoughts about this are really appreciated!
While on the Mac Mini PowerPC, I just tried to upload something on another Arduino via the Arduino IDE and it got stuck. I tried quitting and I get the same problems I experienced with the Max Runtime.
I might have something to do with the serial, PowerPCs and Arduino. :(
All the best,
ygreq
PS: If any of you guys reading this experienced something similar and/or know how to fix this, please, don't hesitate to write here about it!
PS2: The only difference now is that the mac restarted by itself. (But still I couldn't force quit Arduino IDE and everything else I mentioned it happened with Max runtime.)
UPDATE:
After testing for about 2 weeks on my Mac mini and my Macbook Pro, I found out that what I experience is related to [shellAccess] and [shell] not working with the commands I give them. It is not related to arduino in any way (what I mentioned in the above post is incorrect).
The only test I still want to try is to send "date" messages every 2 seconds to the [shellAccess] mxj object to see if similar things happen. The conclusion would be that the errors are related to either cURL commands to the [shellAccess] object or they are related only to the fact that the object can not handle messages being sent to it every 2 seconds for a long time (less than 24h).
Thank you once again, Zachary for the object and for all your help. Unfortunately it seems I can not use it for what I want to achieve.
All the best to you,
ygreq
Sorry to hear that ygreq. FWIW, I've used both [shell] and [mxj shellAccess] for extended periods without any of the behavior described here. It seems that it might be related to the commands that you're running and/or their regularity. You might want to play around with the garbage collection parameters in max.java.config.txt
Anyways, good luck finding a solution!
best,
Zachary
Hello Zachary,
Just had crashed both in Max 5 and Max 6 after clicking on ifconfig. Should this command be avoided or is this a sign of an instability? My system is Mac OS X 10.7.3, MacBook Pro 17" 2.93 GHz.
Thread 0 Crashed:: Java: AWT-AppKit Dispatch queue: com.apple.main-thread
0 com.cycling74.MaxMSP 0x0001c1ff typedmess_lookup + 59
1 com.cycling74.MaxMSP 0x000641e9 outlet_anything + 603
2 com.cycling74.MaxAPI 0x01b93441 outlet_anything + 60
3 com.cycling74.MaxMSP 0x000331c2 defer_exec(_defer*) + 60
4 com.cycling74.MaxMSP 0x0002a713 sched_dequeue + 119
5 com.cycling74.MaxMSP 0x00012433 max_tick + 77
6 com.cycling74.MaxMSP 0x001e4bde maxapplication_eventtimerproc(__EventLoopTimer*, void*) + 22
7 com.apple.HIToolbox 0x98ceb861 TimerVector + 22
8 com.apple.CoreFoundation 0x99407656 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
9 com.apple.CoreFoundation 0x99406fe7 __CFRunLoopDoTimer + 743
10 com.apple.CoreFoundation 0x993e5f70 __CFRunLoopRun + 1888
11 com.apple.CoreFoundation 0x993e547c CFRunLoopRunSpecific + 332
12 com.apple.CoreFoundation 0x993e5328 CFRunLoopRunInMode + 120
13 com.apple.HIToolbox 0x98cd017f RunCurrentEventLoopInMode + 318
14 com.apple.HIToolbox 0x98cd74e7 ReceiveNextEventCommon + 381
15 com.apple.HIToolbox 0x98e6d2e4 ReceiveNextEventInMode + 67
16 com.apple.HIToolbox 0x98e6d37c ReceiveNextEvent + 72
17 com.cycling74.MaxMSP 0x002d375e juce::juce_dispatchNextMessageOnSystemQueue(bool, bool) + 554
18 com.cycling74.MaxMSP 0x002dd3e3 juce::MessageManager::dispatchNextMessage(bool, bool*, bool) + 79
19 com.cycling74.MaxMSP 0x002dd4a2 juce::MessageManager::runDispatchLoop() + 42
20 com.cycling74.MaxMSP 0x002dbdfd juce::JUCEApplication::main(juce::String&, juce::JUCEApplication*) + 605
21 com.cycling74.MaxMSP 0x002dbed7 juce::JUCEApplication::main(int, char**, juce::JUCEApplication*) + 125
22 com.cycling74.MaxMSP 0x001e5022 main + 76
23 com.cycling74.MaxMSP 0x000059ee _start + 216
24 com.cycling74.MaxMSP 0x00005915 start + 41
Hi George,
Works fine for me on 10.7.2, Macbook Pro 15" 2.2GHz Intel Core i7
Does the same thing happen for you with the shell object? Do you have the most recent version of shellAccess (last attachment in this thread? Try sending it to print or message box or capture, and see if things change, then let me know.
best,
Zachary
From now on, I'll make sure the newest version is here: http://www.zacharyseldess.com/software.html
I had the same version from February 4. Strangely, it worked now after I moved the files into the Max6/Cycling '74/ Java folder. Before, I had invoked ShellAccess from the Downloads folder, and everything worked except ifconfig!
Thanks, Georg