Running a script with cyradm throwing ReadLine errors

[Binarus]

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
>