3 ms·

>It's also a uniquely eurocentric conceit that text is a simple stream of bytes. At the very least, it is a stream of bytes with an encoding label. Unicode is e

>It's also a uniquely eurocentric conceit that text is a simple stream of bytes. At the very least, it is a stream of bytes with an encoding label. Unicode is everywhere, and for some people is required to express their language. You can no more safely assume ISO-Latin-1 as you can UTF-8 or UTF-16. True, but how many of your text-processing utilities need to account for that? Most config file parsers will just continue to work if you insert UTF-8 into the stream, so long as you keep the markers it's working with the same. >We live in a world where Curling JSON objects or (even more problematically) protobuffs objects is the de-facto way we interact with the vast majority of remote services. Feel free to try and fit every workflow you have into jq. Feel free to keep working in an environment where even functional return values are not allowed and you keep repeating the same commands over and over. ...I don't. Protobufs might have a market share in some places, but JSON has decent shell tooling, and you can often convert JSON to DSV in a pinch. I don't understand what you mean by "functional return values not allowed." Sure, EIAS is in full effect, but Shell pipelines are as functional as they come. And I don't repeat the same commands over and over. If I did, I'd give that set of commands a name. >Quick question though: how is it this any different from the plugin approach from gulp? :) Primary difference: The libraries are all already there, you don't have go get apt-get integration for the components you need, and it's often pretty quick to write what you need. Verobosity is a huge problem. Most of the time with a shell, you'll be writing one-off scripts, or doing something interactive. If you were going to write something more than about 50 lines, or more complex than a couple of pipelines or an execution wrapper, you wouldn't be writing shell. PS is trying to go in a different direction, be a language for even those things that you'd go to another language for, but we've got perfectly adequate languages for that, tons of them, and it fails at things that shell is good at.

KirinDave 10y ago
> True, but how many of your text-processing utilities need to account for that? I'm not chinese, but I can have sympathy for people who are. Also who are you to tell me [UTF-8 character removed because of bad assumptions in server code] is not a valid bash variable? > The libraries are all already there, you don't have go get apt-get integration for the components you need, and it's often pretty quick to write what you need. This is an assumption that's very brittle though. For example, which version of Python did you target with this helper script? Do you know? And why is that diff for Powershell? It's just a shell with better affordances for automation than bash. > Verobosity is a huge problem. If you want a less verbose set of powershell commands, try the latest powershell. Nearly everything you type has a short analogue. Function syntax is shorter. It's easier to do things like automate opening of remote connections (e.g., no need for a shell script to open an ssh connection and toss many streaming outputs into it on an ongoing basis). > and it fails at things that shell is good at. You say this but my experience has been the opposite thus far. Making functions actually functions, for example. It's amazing to be able to make a complex jq query repeatable without being forced to pipe everything over an IO stream and collect into a file and then VAR=$(cat result.json).
- qwertyuiop924 10y ago
  Well, the verbosity drop is good. >This is an assumption that's very brittle though. For example, which version of Python did you target with this helper script? Do you know? And PS, and every other piece of software out there doesn't have that problem? Don't make me laugh. >And why is that diff for Powershell? It's just a shell with better affordances for automation than bash. But shell doesn't nessarily need automation affordances: we have Python/Perl/Ruby for that. What it does need is effective interactive use, which is where I think bash has PS beat. >I'm not chinese, but I can have sympathy for people who are. Also who are you to tell me [UTF-8 character removed because of bad assumptions in server code] is not a valid bash variable? That's a problem with Bash itself, which wasn't what I was talking about. My point was that text processing scripts (sed scripts, awk scripts, scripts using cut, etc.) won't choke on unicode, and frequently work pretty much as expected, so long as the tool versions involved can handle unicode, and sometimes even if they can't. If bash has broken unicode support right now, that's not a problem with the paradigm, that's a problem with bash itself, which can be fixed.
  - KirinDave 10y ago
    Cut is not encoding aware... not all Linux distribution have encoding aware grep, and even then you'd need to tell them which encoding to use in many cases. And I don't mean to say any one tool is free of version conflicts, but relying on many tools means relying on many versions. Reducing your total dependency graph is a lesson many language environments have taken from the mess of Java and C++.
    - qwertyuiop924 10y ago
      Well, considering that the primary function of a shell is to run programs, reducing your depgraph isn't what you want.
      - KirinDave 10y ago
        > considering that the primary function of a shell is to run programs The instant we start talking about automation then the repeatability of your automation has to be considered. The shell is arguably an environment for interactive programming as much as it is a shorthand for program invocation.

KirinDave 10y ago

> True, but how many of your text-processing utilities need to account for that? I'm not chinese, but I can have sympathy for people who are. Also who are you to tell me [UTF-8 character removed because of bad assumptions in server code] is not a valid bash variable? > The libraries are all already there, you don't have go get apt-get integration for the components you need, and it's often pretty quick to write what you need. This is an assumption that's very brittle though. For example, which version of Python did you target with this helper script? Do you know? And why is that diff for Powershell? It's just a shell with better affordances for automation than bash. > Verobosity is a huge problem. If you want a less verbose set of powershell commands, try the latest powershell. Nearly everything you type has a short analogue. Function syntax is shorter. It's easier to do things like automate opening of remote connections (e.g., no need for a shell script to open an ssh connection and toss many streaming outputs into it on an ongoing basis). > and it fails at things that shell is good at. You say this but my experience has been the opposite thus far. Making functions actually functions, for example. It's amazing to be able to make a complex jq query repeatable without being forced to pipe everything over an IO stream and collect into a file and then VAR=$(cat result.json).

qwertyuiop924 10y ago
Well, the verbosity drop is good. >This is an assumption that's very brittle though. For example, which version of Python did you target with this helper script? Do you know? And PS, and every other piece of software out there doesn't have that problem? Don't make me laugh. >And why is that diff for Powershell? It's just a shell with better affordances for automation than bash. But shell doesn't nessarily need automation affordances: we have Python/Perl/Ruby for that. What it does need is effective interactive use, which is where I think bash has PS beat. >I'm not chinese, but I can have sympathy for people who are. Also who are you to tell me [UTF-8 character removed because of bad assumptions in server code] is not a valid bash variable? That's a problem with Bash itself, which wasn't what I was talking about. My point was that text processing scripts (sed scripts, awk scripts, scripts using cut, etc.) won't choke on unicode, and frequently work pretty much as expected, so long as the tool versions involved can handle unicode, and sometimes even if they can't. If bash has broken unicode support right now, that's not a problem with the paradigm, that's a problem with bash itself, which can be fixed.
- KirinDave 10y ago
  Cut is not encoding aware... not all Linux distribution have encoding aware grep, and even then you'd need to tell them which encoding to use in many cases. And I don't mean to say any one tool is free of version conflicts, but relying on many tools means relying on many versions. Reducing your total dependency graph is a lesson many language environments have taken from the mess of Java and C++.
  - qwertyuiop924 10y ago
    Well, considering that the primary function of a shell is to run programs, reducing your depgraph isn't what you want.
    - KirinDave 10y ago
      > considering that the primary function of a shell is to run programs The instant we start talking about automation then the repeatability of your automation has to be considered. The shell is arguably an environment for interactive programming as much as it is a shorthand for program invocation.