Dear ellie,
On 19.12.2018 01:38, ellie timoney wrote:
>> Then I have replaced the following code in Cyrus::IMAP::Shell
>
> That's very interesting. Does the same modified code continue to work if you uninstall Term::Readline::Gnu again? That is to say, does the non-gnu version break with that addition, or continue to work?
I have just done that test: Yes, the same modified code continues to
work even if Term::ReadLine::Gnu is uninstalled, i.e. my "patch" does
not break the non-gnu version.
>> In other words, I just have made sure that this mysterious *__DATA__
>> variable is reasonably defined in every case before _run is called.
>
> I had a look in Shell.pm and found this comment near the top:
>
>> # run(*FH|'FH')
>> # read commands from the filehandle and pass to exec(); defaults to
>> # __DATA__
I also had seen this comment, but couldn't make any sense from it.
> So maybe that explains where the expectation for __DATA__ is coming from... so:
>
>> # trivial; wrapper for _run with correct setup
>
> I wonder if the "correct setup" is not correct enough!
There are many aspects I didn't understand yet. To me, it seems that
_run is called with a bunch of uninitialized parameters. For example,
where are $cyradm and *__DATA__ initialized? I am currently lacking the
time to do my homework (i.e. to completely understand how this is
supposed to work under normal circumstances), so I don't want to let
other persons waste their time for explaining it to me ...
However, despite the fact that I haven't grasped the overall concept
yet, there is obviously a bug with parsing the command line.
>> I have no idea why the "buggy" command line / argument parsing does not
>> strike when Term::ReadLine::Gnu is uninstalled; I haven't grasped yet
>> how *__DATA__ is supposed to be assigned a reasonable value to during
>> the normal course of execution. I currently can only speculate that
>> Term::ReadLine::<default stub> does this for us, while
>> Term::ReadLine::Gnu doesn't.
>
> I did a bit of reading, and apparently Term::ReadLine is a stub module that just loads "an implementation", which in your case wants to be Term::ReadLine::Gnu. My guess is that, when you uninstall Term::ReadLine::Gnu, Term::ReadLine no longer successfully compiles because it's missing an implementation, and consequently the fallback code I pointed out previously is used instead. So, from this I'm concluding that the "correct setup" from above is adequate for the Cyrus::IMAP::DummyReadline interface, but is not sufficient for a real ReadLine implementation. Sounds like we've found our bug!
I have come to a similar conclusion, and "not sufficient" in this case
probably means that *__DATA__ is not initialized (or assigned to)
correctly. I still have no idea which part of the program is responsible
to assign it the desired file descriptor under normal circumstances.
Possibly Cyrus::IMAP::DummyReadLine does initialize *__DATA__ correctly
(because that module knows who it belongs to :-) and what is needed
later), while Term::ReadLine::Gnu can't know about *__DATA__'s existence
at all. But this is just a completely uneducated guess.
> I'll have a bit of a play with it and see if I can find/fix the discrepancy between the interfaces :)
I'll try to free some time and eventually have a look into
Cyrus::IMAP::DummyReadLine. I think we'll have to find out where
*__DATA__ is normally initialized, and move that initialization to
another place so that it happens regardless of the actual ReadLine "plugin".
> Cheers,
Again, thank you very much for all your help and your support!
Binarus
> ellie
>
> On Wed, Dec 19, 2018, at 5:00 AM, Binarus wrote:
>> Dear ellie,
>>
>> On 17.12.2018 23:57, ellie timoney wrote:
>>> Hi Binarus,
>>>
>>>> Could anybody please tell me what I might do wrong here?
>>>
>>> This kind of smells like maybe your system has two versions of perl installed (or two versions of Term::ReadLine, or maybe even two versions of Cyrus::IMAP::Shell), and they're getting in each other's way?
>>>
>>> I'm having a quick glance at the (2.5.10) source of Cyrus::IMAP::Shell and this caught my eye:
>>>
>>>> # ugh. ugh. suck. aieee.
>>>> my $use_rl = 'Cyrus::IMAP::DummyReadline';
>>>> {
>>>> if (eval { require Term::ReadLine; }) {
>>>> $use_rl = 'Term::ReadLine';
>>>> }
>>>> }
>>
>> I have done some further investigations (very roughly because I don't
>> have the time at the moment). It seems that the code which parses the
>> command line and the run parameters in Cyrus::IMAP::Shell is buggy (or
>> at least not prepared to handle Term::ReadLine::Gnu).
>>
>> As a proof, I have reinstalled Term::ReadLine:Gnu and verified that the
>> problem was showing again.
>>
>> Then I have replaced the following code in Cyrus::IMAP::Shell
>>
>> # trivial; wrapper for _run with correct setup
>> sub run {
>> my $cyradm;
>> _run(\$cyradm, [*STDIN, *STDOUT, *STDERR], *__DATA__);
>> }
>>
>> by the following code:
>>
>> # trivial; wrapper for _run with correct setup
>> sub run {
>> my $cyradm;
>> open(*__DATA__, "./000");
>> _run(\$cyradm, [*STDIN, *STDOUT, *STDERR], *__DATA__);
>> }
>>
>> In other words, I just have made sure that this mysterious *__DATA__
>> variable is reasonably defined in every case before _run is called.
>>
>> Now the command
>>
>> perl -MCyrus::IMAP::Shell -e 'run("000")'
>>
>> executed without any error message.
>>
>> To verify that the script worked as intended, I added a few lines to it:
>>
>> connect -noauthenticate localhost
>> auth cyrus
>> lm
>>
>> When run as shown above, it did exactly what it was supposed to. It
>> asked for the password and then listed all mailboxes and their subfolders.
>>
>> So now I have at least a system where I can have Term::ReadLine::Gnu
>> installed (and thus can have a history and command editing capabilities
>> in cyradm) _and_ can execute a script, although the script's filename is
>> hardcoded.
>>
>> Probably it would be absolutely trivial for the authors of
>> Cyrus::IMAP::Shell to fix this issue. It would be very nice if somebody
>> could care about it. Perhaps it's already fixed in the newer versions? I
>> am still on 2.5.10.
>>
>> I have no idea why the "buggy" command line / argument parsing does not
>> strike when Term::ReadLine::Gnu is uninstalled; I haven't grasped yet
>> how *__DATA__ is supposed to be assigned a reasonable value to during
>> the normal course of execution. I currently can only speculate that
>> Term::ReadLine::<default stub> does this for us, while
>> Term::ReadLine::Gnu doesn't.
>>
>> Regards,
>>
>> Binarus
>> ----
>> Cyrus Home Page: http://www.cyrusimap.org/
>> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>> To Unsubscribe:
>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
> ----
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
