4 ms·
> But still I'm failing to see what your point is about the "real bash solution" It's accepting that bash sucks at strings, and trying to keep it as far away a
by falsedan 9y ago
> But still I'm failing to see what your point is about the "real bash solution"
It's accepting that bash sucks at strings, and trying to keep it as far away as possible from the data in the pipeline. You keep pointing to the nulls and say, bash is bad at this and oil is good; but it's a strawman since bash doesn't have to even see the nulls for a bash script to be 100% correct at escaping the git log messages.
- chubot 9y agoAs noted in the article, I'm suggesting that the shell itself should able to handle searching a stream for NULs, without this roundabout way of doing things: count-nul() { # -o puts every match on its own line. (grep -o -c doesn't work.) od -A n -t x1 | grep -o '00' | wc -l } You can do this in Python or Perl, but it's not a stretch for the shell to do it directly.
- falsedan 9y agoAnd I’m saying, this isn’t a feature I feel the lack of in bash. If I’m working with non-text data, I’ll move to a language with better handling of complex data structures like perl & explicitly handle concurrency myself. To be clear: oil has to be a compelling alternative to perl, not bash.