Output's lines are split on -char-limit
Closed this issue · 1 comments
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.
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.