John Dekron

I am using your UB shell object. On a Mac Pro 2.66 GHz I do not receive 

an output from the left outlet. but the object seems to execute the 

entered commands (i. e. lp starts the printing process). Using this 

steps to reproduce: download the object. double click the helpfile. 

->there is only the bang from the right output displayed in the Max window.

Max 1.6.2, MacOS X 10.4.7, Mac Pro 2x2.66 Dual Core Intel Xeon

Hi Jeremy,
I am using your UB shell object. On a Mac Pro 2.66 GHz I do not receive 
an output from the left outlet. but the object seems to execute the 
entered commands (i. e. lp starts the printing process). Using this 
object on a PPC seems to work fine.

steps to reproduce: download the object. double click the helpfile. 
->there is only the bang from the right output displayed in the Max window.

shell-ub-bug-on-intel-mac

Not to the best of my knowledge, although I have no access to a 

machine which exhibits this behavior, in any case...

Not to the best of my knowledge, although I have no access to a  
machine which exhibits this behavior, in any case...

> My question:
> Perhaps OS 10.4.8 solves this problem?


in any case I would be glad to give you access to the machine that has 

> Not to the best of my knowledge, although I have no access to a 

> machine which exhibits this behavior, in any case...

> Am 16.10.2006 um 13:05 schrieb Eric L.:

>> Perhaps OS 10.4.8 solves this problem?

in any case I would be glad to give you access to the machine that has 
the problem. just let me know.

Jeremy Bernstein schrieb:
> Not to the best of my knowledge, although I have no access to a 
> machine which exhibits this behavior, in any case...
>
> jb
>
> Am 16.10.2006 um 13:05 schrieb Eric L.:
>
>> My question:
>> Perhaps OS 10.4.8 solves this problem?
>
>


Just wondering if anyone's still working on this? I've tried everything i can think of in dozens of combinations but keep coming back to the fact a "shell" process, started from Max 4.6, on Intel doesn't return it's stdout or stderror streams (either to Max or redirecting into files)

Commands without output seem to work fine.

I have lately been trying to redirect output to an environment variable but my fluency in bash is too limited (must be something like "ls | TEMP=")

There are several other threads where this has been discussed - not sure where to post so i'm replying to all - apologies for repetition (but my whole project is stuck on this at the moment)

This happens with externals or mxj.
Commands without output seem to work fine.

This bug also affects shell commands run from the tap.applescript (but hey, it's only money!) and all my attempts to write a "pure" Java Spotlight routine seem to have failed (mainly cocoa foundation classes which plainly just don't seem to work and calling the carbon routines via a JNI library - just can't get the UB jnilib to function properly - or at all).

If anyone does have a way of getting Spotlight results into Max i would be ever so appreciative (getting on for 4 weeks solid frustration on this so far!)

I seem to have found a workaround for this, at least for my situation (using mxj)

I read this right at the beginning of my investigations

>> This appears to be an Apple issue - we've observed the problem only

>> on some machines (machines I don't have to test with - my MacMini Duo

>> doesn't exhibit the behavior). The output of the object is being

>> redirected to the Console. At this time, there's no workaround.

but that "redirected to the Console" bit didn't sink in.

My workaround (a.k.a. evil hack) involves writing markers out using "echo" before and after running the shell command and then reading my results from console.log (i said it was evil)

If anyone's interested in an example i'll send one over.

Now, what was i supposed to be doing with those results...

> On 9/30/06, Jeremy Bernstein wrote:
>> This appears to be an Apple issue - we've observed the problem only
>> on some machines (machines I don't have to test with - my MacMini Duo
>> doesn't exhibit the behavior). The output of the object is being
>> redirected to the Console. At this time, there's no workaround.

On Feb 26, 2007, at 1:11 PM, Jonny wrote:

> My workaround (a.k.a. evil hack) involves writing markers out using 

> "echo" before and after running the shell command and then reading 

> my results from console.log (i said it was evil)

Glad to see you've found a workaround. Btw, we've been able to solve 

this problem and it will be included in a forthcoming release.

> My workaround (a.k.a. evil hack) involves writing markers out using  
> "echo" before and after running the shell command and then reading  
> my results from console.log (i said it was evil)

Glad to see you've found a workaround. Btw, we've been able to solve  
this problem and it will be included in a forthcoming release.

Thanks, and well done nailing it properly - i look forward to "cleaning" my code!

can you send me an example of this on/off list. cant really wait for the next release. have been trying to echo without success. frustrating.

>My workaround (a.k.a. evil hack) involves writing markers out >using "echo" before and after running the shell command and then >reading my results from console.log (i said it was evil)

can you send me an example of this on/off list.  cant really wait for the next release.  have been trying to echo without success.  frustrating.

>My workaround (a.k.a. evil hack) involves writing markers out >using "echo" before and after running the shell command and then >reading my results from console.log (i said it was evil)


Not intending to be rude but dashing out of the door - will try to respond next week.

No problem, my workaround is just not so clean. Involves writing shell results to a temp file, reading the results, and then rm the file.

No problem, my workaround is just not so clean.  Involves writing shell results to a temp file, reading the results, and then rm the file.

> No problem, my workaround is just not so clean. Involves writing shell results to a temp file, reading the results, and then rm the file.

that actually doesn't sound like too bad a solution, given the circumstances. 

also, make sure you have a good look at java too, as that is how i solved my missing shell woes. for instance the following very simple mxj file replaces "shell ls":

compile and load this in to mxj and send it "ls path/to/folder"

    public void anything(String arg, Atom[] args) 

            File file = new File(args[0].toString());

            if(file.exists())

                String[] files = file.list();

                for(int i=0; i

                    if(!files[i].startsWith("."))

                        outlet(0, files[i]); 

                }                    

                post("Error: can't find file: " + args[0].toString());

            post("Did not recognize command " + arg);

> No problem, my workaround is just not so clean.  Involves writing shell results to a temp file, reading the results, and then rm the file.

that actually doesn't sound like too bad a solution, given the circumstances. 
also, make sure you have a good look at java too, as that is how i solved my missing shell woes. for instance the following very simple mxj file replaces "shell ls":
compile and load this in to mxj and send it "ls path/to/folder"

import com.cycling74.max.*;
import java.io.*;

public class JShell extends MaxObject {
	//private shell mShell;
	public JShell() {
		post("JShell:  -ls");
		declareIO(1,1);
	}
	public void anything(String arg, Atom[] args) 
	{ 
		if(arg.equals("ls")) { 
			File file = new File(args[0].toString());
			if(file.exists())
			{
				String[] files = file.list();
				for(int i=0; i
				{
					if(!files[i].startsWith("."))
						outlet(0, files[i]); 
				}					
			}
			else
				post("Error: can't find file: " + args[0].toString());
		}
		else
		{ 
			post("Did not recognize command " + arg);
		} 
	} 	
}


will take a look, have tried java to shell without feedback on ub machine. tis why i opt for this workaround.

will take a look,  have tried java to shell without feedback on ub machine.  tis why i opt for this workaround.

>my workaround is just not so clean. Involves writing shell results to a temp file, reading the results, and then rm the file.

To me that sounds less evil that my solution - i tried for a week or two but couldn't get the shell to redirect the output _anywhere_! (my knowledge of sh etc is decidedly limited).

I'm opening up a temporary system file (/Library/Logs/Console/501/console.log), which i was half expecting to have to hack the permissions on to read, and then look for "errors" that i'd deliberately caused - it's also done in Java so a shell only solution sounds far cleaner and lighter to me.

I can still try to clean up my example for you (all) to have a look at but i'm really not very proud of it ;P and hopefully soon (?) it will be unnecessary.

Ryan wrote:
>my workaround is just not so clean. Involves writing shell results to a temp file, reading the results, and then rm the file.

Well, on a second check, my workaround is not working after all. On my pb, yes, but ub mac-pro no. Am able to create a tmp file, but shell writes no data to it on the ub. Hmmm. Also tried java a while ago with no success. Ready to go the evil route. Would like to see your patch regardless of clean or dirty bits.

Well, on a second check, my workaround is not working after all.  On my pb, yes, but ub mac-pro no.  Am able to create a tmp file, but shell writes no data to it on the ub.  Hmmm.  Also tried java a while ago with no success.  Ready to go the evil route.  Would like to see your patch regardless of clean or dirty bits.

That's exactly where i got stuck - even tried all sorts of command scripts opening new shell processes and everything but with no joy (sort of glad i hadn't missed anything ;)

I'll do the tidy on my thing and upload it somewhere (here?)

thank you, have been able to echo to log and but not in all cases. can emil example to {float at 474746 dot org}

thank you, have been able to echo to log and but not in all cases.  can emil example to {float at 474746 dot org}
thanks
ryan


Looks like the latest version of Max (4.6.3) now does solve this problem properly - i still have the workaround/hack in my code in case somehow it ends up running in a 4.6.2 runtime environment on Intel, so can share it if you need it...

However i strongly recommend everyone upgrades to the new version as soon as possible!

shell UB bug on Intel Mac