Output's lines are split on -char-limit

[justinsteven]

Notify version:

% ./notify -version

             __  _ ___
  ___  ___  / /_(_) _/_ __
 / _ \/ _ \/ __/ / _/ // /
/_//_/\___/\__/_/_/ \_, / v1.0.1
                   /___/

                projectdiscovery.io

Use with caution. You are responsible for your actions
Developers assume no liability and are not responsible for any misuse or damage.
[INF] Current Version: 1.0.1

Current Behavior:

-char-limit is used to limit the length of the lines sent to the notification service. This is useful to prevent overly long lines from failing to send, but as a side effect it also mutates the tool's output (which is currently stderr, but might soon be stdout - see #135). This could break usage of notify mid-pipeline to send data to a notification service before further processing is done on it. I'm not sure if putting notify in the middle of a pipeline is an intended or supported use.

Demo:

% cat /etc/issue
Debian GNU/Linux 10 \n \l

% ./notify -i /etc/issue -bulk -char-limit 8

             __  _ ___
  ___  ___  / /_(_) _/_ __
 / _ \/ _ \/ __/ / _/ // /
/_//_/\___/\__/_/_/ \_, / v1.0.1
                   /___/

                projectdiscovery.io

Use with caution. You are responsible for your actions
Developers assume no liability and are not responsible for any misuse or damage.
Using default provider config: /home/justin/.config/notify/provider-config.yaml
Debian G
NU/Linux
 10 \n \
l

Expected Behavior:

-char-limit is respected when sending lines to the notification service, but does not cause the tool's output to also be chunked.

A mock-up of what the above demo should look like (IMO) is as follows:

% ./notify -i /etc/issue -bulk -char-limit 8

             __  _ ___
  ___  ___  / /_(_) _/_ __
 / _ \/ _ \/ __/ / _/ // /
/_//_/\___/\__/_/_/ \_, / v1.0.2-dev
                   /___/

                projectdiscovery.io

Use with caution. You are responsible for your actions
Developers assume no liability and are not responsible for any misuse or damage.
Using default provider config: /home/justin/.config/notify/provider-config.yaml
Debian GNU/Linux 10 \n \l

Steps To Reproduce:

Anything else:

Maybe it's intended that the tool's output is reflecting what was sent to the notification service instead of reflecting the input data. This breaks the use of notify mid-pipeline. However, pee could be a way to use notify mid-pipeline while preserving the integrity of stdin. This should be tested and documented.

[justinsteven]

Update: I have come to really appreciate this behaviour when doing dev and debugging. Without it I don't know that I could have diiagnosed and fixed various problems with line/message length and splitting.

If we do fix it (and I'm starting to think we can't fix it) we should have a debug mode that reverts to the current behaviour of showing what was actually sent to the notification service/s.