The Beauty of Unix Pipelines

Post by junon » Fri, Jun 05, 2020, 4:17 PM UTC

ComputerGuru wrote: post #349

jcranmer wrote: post #38

Earlier quoted context omitted.

> (1) everything is text And lists are space-separated. Unless you want them to be newline-separated, or NUL-separated, which is controlled by an option that may or may not be present for the command you're invoking, and is spelled completely differently for each program. Or maybe you just quote spaces somehow, and good luck figuring out who is responsible for inserting quotes and who is responsible for removing them…

I think this was a failure on behalf of early terminal emulator developers. End-of-field and end-of-record should have been supported by the tty (either as visual symbols or via some sort of physical distancing, etc even if portrayed just as a space and a new line respectively) so that the semantic definition could have been preserved/distinguished.

Post by tsimionescu » Fri, Jun 05, 2020, 4:27 PM UTC

bregma wrote: post #307

tsimionescu wrote: post #256

Earlier quoted context omitted.

I don't think this is the problem people usually complain about. The much bigger problem is that spaces make text-only commands compose badly. $ ls -l `find ./ -name *abc*` Is going to work very nicely if file names have certain properties (no spaces, no special chars), and it's going to break badly if they don't. Quoting is also very simple in simple cases, but explodes in complexity when you add variables and other…

Ah, more problems with shell expansion and substitution. Pipelines to the rescue. If you used a pipeline instead of shell expansion, it can deal with spaces just peachy. $ find . -name "*abc*" -print0 | xargs -0 ls -l There's no argument that bash (and other shells) make dealing with spaces and quotes troublesome. That has nothing to do with pipelines.

    find / -print0 | \
        grep something | \
        xargs -0 cat

Post by gorgoiler » Fri, Jun 05, 2020, 5:04 PM UTC

outadoc wrote: post #259

enriquto wrote: post #258

Earlier quoted context omitted.

> because spaces are a reasonable thing to put in a filename unless you're on a Unix system. Putting spaces on a filename is atrocious and should be disallowed by modern filesystems. It is like if you could put spaces inside variable names in Python. Ridiculous.

You should take a stroll in the real world sometime, where spaces and Unicode exists :)

Post by AnIdiotOnTheNet » Fri, Jun 05, 2020, 5:43 PM UTC

majkinetor wrote: post #356

AnIdiotOnTheNet wrote: post #341

Earlier quoted context omitted.

There are projects like NuShell that are similar to PowerShell but don't rely on .NET.

There is nothing like PowerShell.

Post by laumars » Fri, Jun 05, 2020, 5:56 PM UTC

jyounker wrote: post #354

HeadsUpHigh wrote: post #298

Earlier quoted context omitted.

I'm not going back to CamelCase or underscores for my normal day to day file naming. The problem with spaces only exists inside the IT world and it's something they should find a way around.

At the point I'd be happy if all unix tools had a `--json` option. Then the whole space issue goes away. So do a bunch of parsing issues. Unix tools standardized a character representation (e.g. everything is ascii). The next step is a unified standard the syntactical representation.