Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Alkor San
    @alkorsan
    why both examples don't have the same behavior? can one-argument mode have the same behavior like two-argument mode?or i miss something?
    Vitaly Shukela
    @vi
    It was already discussed before.
    1-arg 2-arg
    text binary
    2 messages 1 message
    no newlines with newlines
    1-arg mode is user-friendly mode, 2-arg mode is raw mode.
    There should be a way to send both messages without newline and with newline. It is not certain which mode should be default. But I expect WebSocket messages to be typically 1-line serialized JSON (without a newline at the end).
    Maybe in future I also add special JSON powers to websocat, so that you can specify {a:5, b:qwer} and it would send {"a":5, "b":"qwer"} (or something like that).
    Alkor San
    @alkorsan
    aaah it is caused by text then , ok ok, then it s logic now , i don t know how new comers will know this by them self, it s imposible to know that difference alone
    Vitaly Shukela
    @vi
    What caused by text?
    In your example you should probably see ABC (without newlines).
    Alkor San
    @alkorsan
    when mode is text websocat will parse the message , that s why it removes \n. and in binary mode websocat don t touch the message, so i think the behavior i had was caused by the text mode as you just explained to me, no?
    Vitaly Shukela
    @vi
    What behaviour?
    Alkor San
    @alkorsan
    the behavior of the 2nd exemple, the message is cutted by \n , and sent without \n
    Vitaly Shukela
    @vi
    websocat ws-l:127.0.0.1:8888 - + printf 'A\nB\nC\n' | websocat ws://127.0.0.1:8888 should give ABC (withhout newlines)
    Alkor San
    @alkorsan
    oops sorry , are you talking about my first issue or my second? i wrote two diferent issues
    maybe I open an issue in github? this is becoming dificult to follow?
    Vitaly Shukela
    @vi
    Of course.
    Alkor San
    @alkorsan
    ok I will open two issues now
    Alkor San
    @alkorsan
    is it correct to say that websocat uses \n as a delimiter? the json may contain \n, or the server may force you to send \n
    why it is not EOF the delimiter?
    Vitaly Shukela
    @vi
    JSON may only contain \n as a whitespace, not as a proper content.

    EOF the delimiter

    What if you want to send multiple messages?

    Alkor San
    @alkorsan
    then -0 is what we need I think
    this will solve a lot of problems
    Vitaly Shukela
    @vi
    is it correct to say that websocat uses \n as a delimiter?
    In --line mode websocat uses \n as a line terminator. In non---line-mode it is just another byte.
    ("delimiter" or "separator" is like , in JSON; "terminator" is like ; in C)
    Alkor San
    @alkorsan
    thank you
    Vitaly Shukela
    @vi
    But in mode without --line, but with --one-message it is indeed more reasonable to read until EOF insteadd of just doing one read operation.
    In TODO list...
    Alkor San
    @alkorsan
    yes
    Vitaly Shukela
    @vi
    Do you think it is a good idea about those [A]s in help message (hiding options from usual help and showing them only in --long-help)?
    Alkor San
    @alkorsan
    in fact a hate command lines that hide the info and you have to read all the short description to know that there is more. but some command lines do this
    there is not a lot of flags , why hide them?
    and this flag is needed for the simple mode --linemode-retain-newlines, i see it s hiding!
    Vitaly Shukela
    @vi

    Because of there are (or will be) many tricky flags that may confuse users.

    Obviously, --long-help and the fact that some flags and options (and later address types) are hidden is mentioned in the help message.
    Try websocat --help.

    --linemode-retain-newlines shouldn't be needed much. Just slap -l on server side part and it would also look more nice.
    Line mode on client should correspond to line mode on server.
    Alkor San
    @alkorsan
    oh i did not know
    I think it s better to have them in the --help not in the --long-help, they don t confuse me , it is the description what confused me in most of the time. the description says something and the flag do more things of what it is told.
    Alkor San
    @alkorsan
    I feel like that you write the description supposing things , and i think the help should not need suppositions but it should show you things without more fiddeling or asking in forums
    Vitaly Shukela
    @vi
    Would just a list of hidden options and flags in --help suffice?
    Alkor San
    @alkorsan
    sorry i did n t get the question, how? you mean to make a list of the hidden flags without description for exemple?
    Vitaly Shukela
    @vi
    One-line list of short and long options. Like (there are hidden options: --linemode-retain-newlines, --dump-spec, .... See --long-help)
    Alkor San
    @alkorsan
    it will make the help very verbose with info that will never be read. but it s better . and what i prefer is leave the flags as they were (there is few ones only) and make better description for them , and hide the specifiers only
    Vitaly Shukela
    @vi
    For example FFmpeg also shows only part of options on usual --help.
    Alkor San
    @alkorsan
    maybe because he have 1 million option :/ and it make it very hard
    even reading the manual of ffmpeg is very hard and tedious
    Vitaly Shukela
    @vi
    Especially about FFmpeg expression evaluator...
    Alkor San
    @alkorsan
    yes I always end up looking for help externally
    Vitaly Shukela
    @vi
    It it a good idea to make --short-help instead with flag and option hiding?
    Alkor San
    @alkorsan
    it will never be used I think, I don t see any use
    --long-help works like man this is the expected