Problem : Shell failed


New Member
Hi, Hippie:

As always, your insights are much appreciated.

After reading your post and after verifying that trying to open the .../Downloads/MaxAXEpad "application" (hey, it's labeled as an "application" but it really is a directory) by double clicking it (or Finder Open) from Finder causes the same "/d/" error, I tried the following execution tests:

1) In a terminal window I followed the MacAXEpad application/directory path to the .../Downloads/MaxAXEpad/Contents/MacOS/ SubR and started ./MacAXEpad from this location, and it worked just fine! No leading "/d/" error. I was able to program an 08M2 w/o any errors!

2) In Finder I did the same thing using the "Show Package Contents" function to open another finder window, drilled down to the MacAXEpad and this worked, too! Also under the Downloads directory.

3) I've since copied the MacAXEpad application/directory to the Applications directory and am NOW able to open it (instead of drilling down to the app itself) just fine by double clicking it using Finder, by using Finder Open and by using a link on my start up bar. They all work fine.

4) Just to make sure it wasn't a temporary fix, I have rebooted MacBookPro and am still able to use MacAXEpad as described in test number 3 above.

So in my case it seems that this erroneous "/d/" path insertion only occurs when trying to start the MacAXEpad from .../Downloads/MacAXEpad using Finder.

Thanks for your help Hippie: you rock!



Technical Support
Staff member
So in my case it seems that this erroneous "/d/" path insertion only occurs when trying to start the MacAXEpad from .../Downloads/MacAXEpad using Finder.
Many thanks for your efforts. You have been a great help and it seems we may have got to the bottom of the issue.

It is a bit odd that Mac OSX allows things to be run from Downloads but doesn't allow the Linux it relies on access to the same.

It will be interesting to see if the fix works for others having the same issue. I suspect it will.

I am not familiar with Macs but thought that the process to install MacAXEpad was to download, double click on what's downloaded and that would install the application and create a desktop icon for that. Clicking the icon should then run the app, not what was downloaded.

With hindsight, if "/d" had been "/downloads", we might have suspected the issue related to where things were and that it may have been because of a sandboxed download area issue. Unfortunately it's easy to be misled into thinking that "/d" is what it should be and what it would be for any app run.

Going back to an earlier post -
//pwd gives:
That suggest that though Samuelsoul had installed it as an application, or the Mac was happy to accept it was, it was still telling MacAXEpad that it was in /d when it ran.

I would suspect this is the real underlying problem, would guess that earlier versions of Mac OS were not doing that.
Last edited: