bus error with 'open' command

soellman

nice face!
So the 'open' command is a good one, from the command line you can open things in the finder or start applications. It's much like the 'start' command in windows. you can open a file, application, or directory and up it pops in the finder.

Unless you're running 10.1! I tried it today to find that it gave me a bus error. Chalk up another bug..
 
Originally posted by Red Phoenix
How are you trying to use it? It still works fine for me in OS X.I.
huh.
[think:/Volumes/space/src] oliver% open .
Bus error
[think:/Volumes/space/src] oliver%

I need to do a clean install in any case, this install has been upgraded through from 10.0.4..
 
I updated through 10.0.4, too, but had no problems. There was a thread about certain command-line tools not getting updated. There was something about people running the Essentials.pkg again, but I didn't read it fully.
 
Originally posted by Red Phoenix
I updated through 10.0.4, too, but had no problems. There was a thread about certain command-line tools not getting updated. There was something about people running the Essentials.pkg again, but I didn't read it fully.
well let's see..

[think:/Volumes/space/src] oliver% ls -l `which open`
-r-xr-xr-x 1 root wheel 22336 Sep 11 03:43 /usr/bin/open

can you do the same?
cheers
 
I get

-r-xr-xr-x 1 root wheel 22336 Sep 11 06:43 /usr/bin/open

It's too bad they don't give a way to check the version number of open, but based on this I'd say that they're the same. I wish I knew how to help you in this case. I do that open has been working for myself and others, though, so this is very strange.
 
Try 'what':


localhost:/Users/blb $ what /usr/bin/open
/usr/bin/open
PROGRAM: open PROJECT: open-139 DEVELOPER:root BUILT:02/17/01 15:17:34


This is on a 10.0.4 box, so 10.1 should have a later build and project version...
 
Using what `which open` gives

/usr/bin/open
PROGRAM:eek:pen PROJECT:eek:pen-150 DEVELOPER:root BUILT:09/03/01 03:07:31


on an OS X box, just so you know.
 
Originally posted by Red Phoenix
Using what `which open` gives

/usr/bin/open
PROGRAM:eek:pen PROJECT:eek:pen-150 DEVELOPER:root BUILT:09/03/01 03:07:31


on an OS X box, just so you know.
same here.. if I could remember the syntax to nm I'd see which dynlibs it's trying to use, that could well be the problem..
 
Originally posted by soellman

if I could remember the syntax to nm I'd see which dynlibs it's trying to use, that could well be the problem..

Do you mean,


localhost:/Users/blb $ otool -L /usr/bin/open
/usr/bin/open:
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 577.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 397.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 50.0.0)
 
Originally posted by blb


Do you mean,


localhost:/Users/blb $ otool -L /usr/bin/open

that's the one :)

[think:/Volumes/space/src] oliver% otool -L /usr/bin/open
/usr/bin/open:
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 617.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 423.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 55.0.0)
 
It's the same for my working version of open in X.I:

/usr/bin/open:
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 617.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 423.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 55.0.0)
 
I found that "open" sometimes works, sometimes it crashs with a bus error. And when I call it with absolute path (e. g. "/usr/bin/open ."), it always works. I assume there is a problem with looking up the application to use to open the given file. But as far as I see, the "open" sources are not included in the Darwin open sources, so we can't debug it.
 
So I think the problem might have been my screwy lookupd configs, which were only half working for a while. When lookupd is broken, many shell commands bus error on ya (the ones that use lookup services, like finger, ls breaks, others)..
 
Back
Top