Bash

Has pretty much everything you may need, except for a TCP/UDP server functionality.

I mean, if it has a built-in TCP client -- why not create simplistic TCP server?
WHY???

There's nc (netcat)

I bet you can make it into a tcp/udp server with some bash around it!

Is that what you mean?

I guess now we just wait for someone to write a javascript engine + framework that will run purely on bash

@theKarlisK There were multiple attempts, yes.

One of them was mine too: https://gitlab.com/netikras/bhttp

But that's not the point. Using nc, socat, etc. is not a bash server. It's a nc server, socat serer, etc. server.

Bash has a built-in TCP client
```
netikras@xps:~$ exec 3<>/dev/tcp/google.com/80
netikras@xps:~$ echo -e "GET /\r\n\r\n" >&3
netikras@xps:~$ cat <&3
HTTP/1.0 200 OK
Date: Mon, 14 Dec 2020 15:16:02 GMT
Expires: -1
.....
```

but it doesn't have a built-in tcp server. Meaning a TCP server I would not have to worry about installing netcat, socat, other utilities for.

CC: @Hazarth

@Hazarth yes, you can build a server using nc. However, there are multiple versions of netcat (e.g. gnu, BSD, busybox, ...), which makes such a server non-portable and dependent on the nc's vendor, not just a version.

As for "version dependency" -- consider the nc's -e option:

```
netikras@xps:~$ man nc | grep " -e"
There is no -c or -e option in this netcat, but.....
```

@netikras ooh, I didn't even think about that. That's fair hmm

Yeah I don't know of any way to serverize bash without using an outside utillity like nc or sc either. I see your point... So close, yet so far

@theKarlisK you naughty.... :D

Nevertheless, I'd really like to get rid of those 3 dependencies that I have to maintain due to bash's lack of TCP server functionality:

nc
mkfifo
rm

@Hazarth oh no...

> WHY??!?!1111

Because we don't add jokes into popular tools. ;)

@junon please elaborate?

In what way is a TCP server-socket a joke? :)

@netikras Bash is not a language you should be writing servers in. Period.

@junon

daamn, I must have missed that in the bash's manpages.

Is there a finite list of languages I SHOULD be writing servers in?

@junon A real-life use case (where I needed an as simple as possible webserver to serve 1 request at a time):

k8s liveness checks. There's a containerized application instance and I need to run a h/c on that app. The h/c requires some logic: to fetch data from the endpoint, transform it, verify the output does not include particular strings and the output is formatted correctly.

For this simple as hell task I needed to install a full blown Python runtime and bind + accept(1) (because anything >1 will taint the h/c), where I could have simply used bash, that comes bundled with the docker image had it supported server sockets.

Also, "shouldn't do" != "mustn't be able to do"

@netikras

> Also, "shouldn't do" != "mustn't be able to do"

In this particular case, yes. The people who implement shell scripting should not be troubled to write a POSIX-style API over top of socket functions simply because a few people want it and don't want to take the time to write a real solution.

You're arguing for scope creep, more maintenance burden on shell implementors/maintainers, all for a feature that is remotely useful at best and disastrously problematic at worst.

@netikras

> daamn, I must have missed that in the bash's manpages.

Yeah you did. You're also arguing for a ridiculous feature.

@junon Why posix-style? I don't see anything posix-style in bash's TCP client :) Also, bash has so many bashism which are non-posix which makes it easier to use. The same could be said about other shells: fish, ksh93 (korn), zsh, etc. I don't think posix-compliance is a valid variable here.

As for ridiculousness of the feature - it doesn't make me want it less. It doesn't make less annoyed by bash any less.And I'm not really the only person who lacks this feature - there are many more asking about it

@netikras Because the socket calls are POSIX specified. So is shell scripting, to an extent. So you'd create a set of APIs that mimicked those.

There's absolutely no reason to include TCP inside of bash. That is not what shell scripting is for.

If you're annoyed by shell scripting not giving you direct access to TCP, you're out of luck. Learn a different language for that. Python is stupid easy to write network stuff in. So is Node.js.

@junon yes, unix sockets are posix-specified. But noone says shells must be 100% posix-compliant, nor that shells must only implement POSIX and nothing else, i.e. the socket API shell exposes does not have to be anything posix.

I can implement the socket in other means, but that's not the point. My point was that bash already has a built-in TCP client (!!!), but it lacks a tcp server (which is not that much more difficult to implement, really).

TCP is already in bash - it's not a question of whether or not it belongs there -- it ALREADY is there. It's just only 50% implemented - only the client side..

@netikras Maybe we need a new shell: tcpsh. Then people can complain there is no udpsh.

Also, you can do one liner (at least you could in Python 2) webservers. So you could do one in Python. I have not played with this feature in Python 3 however.

@Demolishun and icmpsh!

@Demolishun It's mostly the same in Python 3, just a different package IIRC.

@netikras because of this i use socat. tcp, udp, unix, stdin/stdout, tls, tls over udp all mixable.