on *:parseline:out:*: has trailing $lf

When you use ON PARSELINE to process outbound messages, $parseline has a hidden $LF as the last character.

Code:

on *:parseline:out:*:echo -s $parsetype $asc($right($parseline,1)) $parseline

As an example, "/LUSERS" produces:

Code:

out 83 10 LUSERS

[11:17:05] There are 1060 users and 805 invisible on 22 servers
[11:17:05] 27 operator(s) online
[11:17:05] 952 channels formed
[11:17:05] I have 167 clients and 1 servers
[11:17:05] Current Local Users: 167  Max: 276
[11:17:05] Current Global Users: 1865  Max: 2312

Note the blank line between the echo and the command output. This is not visible in mIRC but when you copy and paste into this forum it appears - it is the hidden $LF.

Thanks for your bug report. The linefeed you are seeing is part of the line that is being sent to the server.

Yes - but that doesn't mean that it should be returned as part of $parseline.

According to IETF RFC 2812, all messages should be terminated by $CRLF, not $LF. So if I agreed with your logic, then I would expect $parseline to end with $crlf not just $lf. (It seems very odd to strip the penultimate $cr character and leave $lf. It also seems inconsistent for ON PARSELINE IN lines not to have a trailing $lf.)

My point, however, is that this is both unnecessary (because you can assume that the message sent to the server was terminated by a $LF or $CRLF), but also counter-intuitive (since every other example in mIRC does not include a trailing $lf) and confusing (because the $lf is invisible).

This is what the parseline feature is for. It returns the line exactly as it is before it is sent to the server. mIRC sends all lines to the server ending in a $lf. As a scripter, you will need to cater for how parseline works in order to use it.

1. According to the IRC spec the line should be terminated with a $CRLF not a $LF. But there is no $CR in there as you would expect.

2. According to this philosophy, IN lines should also have a $CRLF or $LF at the end because that is part of the line as it is received from the server.

As I said, it is inconsistent as well as non-intuitive.

Quote:

1. According to the IRC spec the line should be terminated with a $CRLF not a $LF. But there is no $CR in there as you would expect.

That's right, mIRC has always sent $lf terminated lines to the server. There are no plans to change this. It is actually mentioned in RFC1459 that a server will accept cr/lf/crlf as end of line markers.

Quote:

2. According to this philosophy, IN lines should also have a $CRLF or $LF at the end because that is part of the line as it is received from the server.

For a number of reasons, it had to be implemented in the current way. It is impossible to change it. So you simply need to be aware of this when using parseline.

I have added a note about this to Wikichip.

As you say, so long as you are aware that you need to strip a trailing $LF, there is no real issue.

P.S. Another oddity is that the text is accessed through $parseline rather than through $1-. It would be nice if it was placed in $1- as well (though if you start your ON PARSELINE with TOKENIZE 32 $LEFT($PARSELINE,-1) you get the same outcome, so this is no big deal either.

For your notes, you will also have to make this consideration for your match-text parameter in PARSELINE events to handle the trailing LF in outbound messages, as well as any colons in either event. The convenient solution is the single character questionmark wildcard.

As in here.

Code:

On *:PARSELINE:out:CAP REQ ?invite-notify?: parseline -ot
;first '?' represents a colon, second '?' represents an $LF