Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

sh : command not found

Strange thing I noticed. I wrote a small plugin for lasso (like php) that
allows a user to send commands to the terminal. I use the popen() to achieve
this. For everything up til now I have never had problems. Someone using it
said that when trying to access image magick they got an error saying
sh: command not found
This occurred using the convert command. First thing that came to mind was
the PATH. I added /usr/local/bin and then I was able to then access convert
thru the terminal. However when thru lasso (the application) I received that
error again. So,
I used /usr/local/bin/convert .... And it seemed to work. Is there somewhere
else other than csh.login where this needs to be edited so that the whole
path is not needed?


Thanks

Steffan

---------------------------------------------------------------
T E L 6 0 2 . 5 7 9 . 4 2 3 0 | F A X 6 0 2 . 9 7 1 . 1 6 9 4
Steffan A. Cline
email@hidden Phoenix, Az
http://www.ExecuChoice.net USA
AIM : SteffanC ICQ : 57234309
The Executive's Choice in Lasso driven Internet Applications
Lasso Partner Alliance Member
---------------------------------------------------------------


> From: Christopher Sean Morrison <email@hidden>
> Date: Mon, 30 Jun 2003 02:04:01 -0400
> To: email@hidden
> Subject: Re: Performance of the Darwin 6.6 Libc malloc()
>
>> I see so maybe you want your allocation rate to be labeled something
>> like GB /s rather ?
>
> This is what the graph units label should indeed read (and what it
> actually did read in a previous incarnation).. The graphs will be updated
> to reflect the proper units of GB/second for the y-axis; thank you for
> noticing this oversight.
>
>> The time used to actually use that kind of memory (f.e. memcpy( dst,
>> src, 100000)) dwarfs the time that the allocation spends. So it is
>> uninteresting.
>
> The test is meant to be a comprehensive analysis of malloc() performance.
> Questions and factors concerning data or memory usage were not within the
> scope of the analysis.
>
> The primary reason for halting the testing at 64 MB size allocations was
> only due to the resolution of the timing mechanisms and memory available
> for allocation. The tests completed too quickly to be comparably
> meaningful across implementations. We found the test and results rather
> interesting regardless; the purpose of the test is to observe and analyse
> the performance of malloc() (only) as it compares to other implementations
> regardless of usage.
>
> Thank you to all who have contacted me with feedback, corrections, and
> comments. Keep it coming. :) Those who have sent me questions and
> concerns will hopefully find them addressed in the final paper.
>
> Cheers!
> Sean
> _______________________________________________
> darwin-development mailing list | email@hidden
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/darwin-development
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: Performance of the Darwin 6.6 Libc malloc() (From: Christopher Sean Morrison <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.