News for hackers. Stuff that matters.
Re:Tup – A file-based build system for Linux, OS X, and Windows by KirinDave on Monday October 03, 2016 @06:36PM (#12631940)
> 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).

Re:Tup – A file-based build system for Linux, OS X, and Windows by qwertyuiop924 on Monday October 03, 2016 @07:58PM (#12632357)
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.

Re:Tup – A file-based build system for Linux, OS X, and Windows by KirinDave on Monday October 03, 2016 @10:23PM (#12632916)
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++.

Re:Tup – A file-based build system for Linux, OS X, and Windows by qwertyuiop924 on Tuesday October 04, 2016 @06:44AM (#12634561)
Well, considering that the primary function of a shell is to run programs, reducing your depgraph isn't what you want.
Re:Tup – A file-based build system for Linux, OS X, and Windows by KirinDave on Tuesday October 04, 2016 @10:55AM (#12635996)
> 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.