Binding on a Port with Netpipes/Netcat

Binding on a port with netpipes/netcat

faucet 10020 --out --daemon \
    echo -ne "HTTP/1.0 200 OK\r\nContent-Length: 4\r\n\r\ntest"

works fine. The issue seems to be that echo doesn't know how to properly shutdown a socket, using just close instead, and curl is unhappy about getting a -1 (disorderly shutdown) rather than a 0 (orderly shutdown) from recvfrom.

Try socat which sticks around to clean up after the child is done.

socat tcp-l:10020,fork,reuseaddr \
    exec:'echo -ne "HTTP/1.0 200 OK\r\n\r\ntest"'

Binding on a port with netpipes/netcat

faucet 10020 --out --daemon \
    echo -ne "HTTP/1.0 200 OK\r\nContent-Length: 4\r\n\r\ntest"

works fine. The issue seems to be that echo doesn't know how to properly shutdown a socket, using just close instead, and curl is unhappy about getting a -1 (disorderly shutdown) rather than a 0 (orderly shutdown) from recvfrom.

Try socat which sticks around to clean up after the child is done.

socat tcp-l:10020,fork,reuseaddr \
    exec:'echo -ne "HTTP/1.0 200 OK\r\n\r\ntest"'

Why do some people exit -1 rather than exit 1 on error?

TLDP's ABS is of questionable validity (in that it often uses, without comment, sub-par practices) so I wouldn't take it as a particular bastion of correctness about this.

That said valid command return codes are between 0 and 255 with 0 being "success". So yes, 1 is a perfectly valid (and common) error code.

Obviously I cannot say for certain why other people do that but I have two thoughts on the topic.

1. A failure to context switch (possibly combined with a lack of domain knowledge).

   In many languages a return value of -1 from a function is a perfectly valid value and stands out from all the positive values that might (one assumes) normally be returned.

   So attempting to extend that pattern (which the writer has picked up over time) to a shell script/etc. is a reasonable thing for them to do. Especially if they don't have the domain knowledge to realize that valid return codes are between 0 255.

2. An attempt to have those error exit lines "stand out" from normal exit cases (which may or may not be successful exits themselves) in an attempt to visually distinguish a certain set of extremely unlikely or otherwise extraordinary exit cases.

   An exit of -1 does, actually, work it just doesn't get you a return code of -1 it gets you a return code of 255. (Try (exit -1); echo $? in your shell to see that.) So this isn't an entirely unreasonable thing to want to do (despite being confusing and complicit in perpetrating a confusion about exit codes).

Can I assume that DOM is not ready yet on dynamically loaded JS script?

You can be almost sure that dom is not ready yet.

This is a good reference to get this working as you want.

I would either:

1) Load dynamically that script and then attach function to onload even to call/do whatever you want with that off-site .js .

2) Load the script only after DOM is ready.

Having a c++ program call an html function/event listener

This is more about c++ to javascript communication than Polymer. But I came across multiple websocket polymer components including this one:

https://github.com/elierotenberg/x-websocket

So you can establish a socket channel between your C++ code and html page:

and attach an event handler to your websocket which triggers the 'show' method of the other component:

var socket = document.querySelector('x-websocket');
var toShow = document.querySelector('#notification')
socket.addEventListner('message', function(data) {

   /* you can get access to the message from c++ code through data object */ 

   toShow.show();

});

There is more info about websockets in c++ here

---

Related Topics