> Hi,
>
> 10x. When you tried this, did you have the debugger connect to Apache HTTPD
> or were you able to somehow execute OTRS's scripts in a more direct way? As
> far as I understood, the Perl interpreter runs in HTTPD's process, via
> mod_perl, so a debugger would need to attach to HTTPD in order to work.
>
> I understand your point about not practically needing the above, but it
> would give me a warm fuzzy feeling to see it working and know I can do that
> for the worst case scenario.
>
> /bogdan
>
> On Tue, Sep 11, 2012 at 10:12 AM, Martin Gruner <
martin.gruner@otrs.com>wrote:
>
>> Hi Bogdan,
>>
>> AFAICT you can use Eclipse with the EPIC perl editor that also includes a
>> graphical interface to the Perl debugger, giving you full execution
>> control. I tried that once, but as Mike said it is not really needed in
>> everyday work.
>>
>> Best regards, mg
>>
>> Am 11.09.12 09:09, schrieb Bogdan Iosif:
>>
>> Thanks for the input.
>>
>> I was "afraid" of that. I'm familiar with this type of debugging from
>> writing shell scripts running under Jenkins but I've never done debugging
>> like that for a code base as large as OTRS seems to be.
>>
>> With shell scripts it was, kind of, simple to assess if the code is valid
>> because I knew exactly where the script will be invoked from and my only
>> concern was to explore the context of the call (mainly env vars). With
>> these Perl scrips, without an IDE that halts execution on a breakpoint or a
>> possibility to statically explore all callers on an object's method, I find
>> it hard to imagine how I can ensure a change I make on some of the code
>> OTRS ships with will not break some code paths or, worse, produce
>> undesirable side effects.
>>
>> I assume you mean Apache HTTPD's STDERR. I'll try to setup Fred. I hope
>> this info is still valid (
>>
http://lists.otrs.org/pipermail/dev/2007-October/001728.html) because I