On Tue, 25 Sep 2012 09:57:54 -0400, Kent A. Reed wrote:
> On 9/25/2012 9:11 AM, Sebastian Kuzminsky wrote:
>> On 09/25/2012 06:42 AM, Gene Heskett wrote:
>>> Am 25.09.2012 um 04:09 schrieb Gene Heskett:
>>>>> Actually, there might be a second way too. If we record the
>>>>> directory
>>>>> path at open time, and then just assume the subroutine is in the
>>>>> same
>>>>> dir as the top level source gcode is.
>>>>>
>> I too sometimes use project-specific subroutines, and like you I'm
>> not
>> totally thrilled to put them in a central place where
>> [RS274NGC]SUBROUTINE_PATH can see them.
>>
>> I think this second option seems like a good idea. Maybe we could
>> have
>> two different CALL functions, like how C has two different #include
>> syntaxes: one for searching the system-wide place only, and another
>> for
>> searching first the current directory then the system-wide place.
>>
>> By "the current directory" I mean the directory of the file running
>> CALL, and by "the system-wide place" i mean the SUBROUTINE_PATH.
>>
>>
>
> I like your analogy to C as a way of illustrating your suggestion but
> perhaps we could just change the behavior of the current syntax to
> search first the current directory and then the system-wide place. Is
> there really a use case that calls for a variant syntax to bypass the
> current directory?
Assuming that you are talking about a PATH list (similar to how most
*NIX shells deal with ${PATH}) then I would suggest not setting the
current directory as the default first choice. Sometimes you want to
explicitly overload something and you need to make sure that you can put
it before the system one. Also, assuming "." or current directory, have
been used in the past to inject trojans and viruses on *NIX machines. I
think we should think twice about allowing that if a rogue subroutine
could be injected...
just my 0.2875 (accounting for inflation).
EBo --
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
