Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] mosquitto-dev Digest, Vol 47, Issue 7

I think the consensus agreement is reached and I agree with it - the
arguments against hex output in mosquitto_sub are:

1.  There are other tools designed to take the output of mosquitto_sub
and do just that (xxd, hexdump, etc), provided the target system has
those tools, and the UNIX philosophy fits better to pipe the output to
those tools
2.  There is not a consistent agreed upon way to show the hex output
3.  Via libmosquitto you can easily write the client you need to fit your needs

These reasons should be sufficient to present to people who ask for
the same in the future.

Regards,
Brandon

On Wed, Nov 22, 2017 at 8:04 PM, Tatsuzo Osawa <tatsuzo.osawa@xxxxxxxxx> wrote:
> Understood your wish.
>
> On the other hand, I guess that the development policy of
> mosquitto_pub/sub client seems to be simple and minimized for a test
> use. Advanced wish should be realized by yourself using libmosquitto.
> (There is no official message about that. Just my guess.)
>
> See also:
> https://github.com/eclipse/mosquitto/issues/587
> https://github.com/eclipse/mosquitto/issues/593
>
> Of course, hex print might be more primitive wish than those.
> But it seems advanced because hex format cannot be determined uniquely.
> e.g.
> 1)  00000000 ab cd ef gh    (with offset)
> 2)  ab cd ef gh  (with delimiter)
> 3)  0xab 0xcd 0xef 0xgh (with prefix)
> 4)  abcdefgh (without delimiter)
> 5)  cdab ghef (little endian)
> ...
>
>
> 2017-11-23 9:15 GMT+09:00 Brandon Arrendondo <barrendo@xxxxxxxxx>:
>> I think piping the mosquitto_sub output to another tool is fine,
>> provided the tools themselves exist on the target machine.  For
>> embedded Linux installs (think busybox/DD-WRT) where tool support
>> (python, etc) is potentially lacking, having the base tools provided
>> by mosquitto provide the capability is a nice to have.
>>
>> It isn't difficult otherwise to write a one-off embedded C client to
>> accomplish the same - I just think if binary payloads are a common
>> part of the MQTT protocol then mosquitto_sub should have some option
>> to support output of them in some way - the default of displaying the
>> characters as ASCII does not work well for binary payloads or
>> (depending on the terminal) unicode payloads.
>>
>> Regards,
>> Brandon
>>
>> On Wed, Nov 22, 2017 at 7:01 PM, Tatsuzo Osawa <tatsuzo.osawa@xxxxxxxxx> wrote:
>>> Hi there,
>>>
>>> There are many wishes for the output format of mosquitto_sub.
>>> I guess, for unix experts, the best way is supporting unix pipe for an
>>> output target of mosquitto_sub.
>>> You can combine any command or text processing with mosquitto_sub to
>>> get your favorite format.
>>>
>>> e.g.
>>> 1) msoqutto_sub -h localhost -t "#" | od -t x         (output binary by hex)
>>> 2) msoqutto_sub -h localhost -t "#" | python -m json.tool     (output
>>> pretty JSON format)
>>>
>>> What do you think about this idea?
>>>
>>> Regards,
>>> Tatsuzo
>>> _______________________________________________
>>> mosquitto-dev mailing list
>>> mosquitto-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/mosquitto-dev
>> _______________________________________________
>> mosquitto-dev mailing list
>> mosquitto-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/mosquitto-dev
> _______________________________________________
> mosquitto-dev mailing list
> mosquitto-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/mosquitto-dev


Back to the top