Nut upsuser - Apr 2022 - NEWLINE

I believe the code only deals with '\n' character for line-breaks, in
protocol and probably configs.

Jim

On Sun, Apr 10, 2022, 19:26 Roger Price <roger at rogerprice.org> wrote:
> The IETF requires that the I-D contain an ABNF (Augmented Backus-Naur
> Form)
> grammar of the NUT commands and responses.  At the end of each command,
> there is
> a NEWLINE character sequence.  The IETF in RFC 5234 say that NEWLINE is
> CRLF,
> carriage return + line feed, hex 0D0A.
>
> Is this true for NUT? The ISE editor requires me to document what NUT
> does, not
> what the IETF propose.  Does upsd accept all forms of NEWLINE or only hex
> 0A?
>
> Roger
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220410/33679dbd/attachment.htm>

On 4/10/22 20:45, Jim Klimov via Nut-upsuser wrote:
> I believe the code only deals with '\n' character for line-breaks,
in
> protocol and probably configs.
>
I've just thrown in a quick test:? I converted upsmon.conf to dos format 
and restarted upsmon. No complains AFAICS so I guess at least upsmon ( 
and I guess the parser is the same for the other apps ) accepts configs 
in CRLF format:


[wolfy at wolfy ~]$ sudo file /etc/ups/upsmon.conf
/etc/ups/upsmon.conf: ASCII text, with CRLF line terminators

[wolfy at wolfy ~]$ sudo systemctl start nut-monitor
Apr 10 21:33:45 wolfy systemd: Started Network UPS Tools - power devices 
information server.
Apr 10 21:33:45 wolfy systemd: Started Network UPS Tools - power device 
monitor and shutdown controller.
Apr 10 21:33:45 wolfy nut-server: fopen /var/run/nut/upsd.pid: No such 
file or directory
Apr 10 21:33:45 wolfy nut-server: Could not find PID file 
'/var/run/nut/upsd.pid' to see if previous upsd instance is already
running!
Apr 10 21:33:45 wolfy upsd[18311]: listening on 127.0.0.1 port 3493
Apr 10 21:33:45 wolfy nut-server: listening on 127.0.0.1 port 3493
Apr 10 21:33:45 wolfy nut-server: listening on ::1 port 3493
Apr 10 21:33:45 wolfy upsd[18311]: listening on ::1 port 3493
Apr 10 21:33:45 wolfy nut-server: Can't chdir to /var/run/nut: No such 
file or directory
Apr 10 21:33:45 wolfy nut-server: Network UPS Tools upsd 2.7.4.1
Apr 10 21:33:45 wolfy upsd[18311]: Can't chdir to /var/run/nut: No such 
file or directory
Apr 10 21:33:45 wolfy nut-monitor: fopen /var/run/nut/upsmon.pid: No 
such file or directory
Apr 10 21:33:45 wolfy nut-monitor: Could not find PID file to see if 
previous upsmon instance is already running!
Apr 10 21:33:45 wolfy nut-monitor: UPS: ablerex at dell3 (primary) (power 
value 1)
Apr 10 21:33:45 wolfy nut-monitor: Using power down flag file /etc/killpower



Please ignore the errors above, I am still fiddling with packaging 2.8.0 
and some things are not yet right.

> Jim
>
> On Sun, Apr 10, 2022, 19:26 Roger Price <roger at rogerprice.org>
wrote:
>
>     The IETF requires that the I-D contain an ABNF (Augmented
>     Backus-Naur Form)
>     grammar of the NUT commands and responses.? At the end of each
>     command, there is
>     a NEWLINE character sequence.? The IETF in RFC 5234 say that
>     NEWLINE is CRLF,
>     carriage return + line feed, hex 0D0A.
>
>     Is this true for NUT? The ISE editor requires me to document what
>     NUT does, not
>     what the IETF propose.? Does upsd accept all forms of NEWLINE or
>     only hex 0A?
>
>     Roger
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220410/77b593f2/attachment-0001.htm>

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net>
writes:
> I believe the code only deals with '\n' character for line-breaks,
in
> protocol and probably configs.
Probably if nut started out as IETF-ish and was mimicking SMTP it would
look for \r\n, but it seems obviously unix-ish (seems normal to me!) and
is \n.   So just documenting that seems good.  That's about the
protocol.

The config file formats are an implementation detail of one
implementation and are thus beyond the scope of the protocol spec -- and
therefore should not be mentioned.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220410/fd01595a/attachment-0001.sig>