Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Beauty of Unix Pipelines

prithu.xyz

Post reply on HN
Print view View original

311–320 of 388 posts

Re: The Beauty of Unix Pipelines

#311

Post by skissane »

enriquto wrote: post #302
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.

I agree. The file load/save dialogs of all GUI should work in such a way that spaces typed by the users in a filename field are always transparently changed to something different (for example, the unicode non-breaking space).

> (for example, the unicode non-breaking space)

That's potentially even worse in a file name than plain old space is. It looks like a normal space, but isn't.

If you are going to replace spaces in file names with something else, underscores are the best option I think.

Re: The Beauty of Unix Pipelines

#312

Post by anthk »

yjftsjthsd-h wrote: post #179
blacksqr wrote: post #127

Earlier quoted context omitted.

> Even Tclsh with readline would be better than a Python shell In fact, I think Tcl would make an excellent sh replacement.

So, wish(1)?

There were attempts in order to create an interactive shell from the TCL interpreter, but the syntax was a bit off (upvar and a REPL can drive you mad), but if you avoided that you could use it practically as a normal shell. Heck, you can run nethack just fine under tclsh.

Re: The Beauty of Unix Pipelines

#313

Post by skissane »

enriquto wrote: post #262
outadoc wrote: post #259

Earlier quoted context omitted.

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

Yeah, any unicode character is OK on a filename, except maybe space and slash.

I don't think C0 or C1 controls should be allowed in filenames.

Why allow them? And they potentially pose security issues.

With some, admittedly somewhat obscure [1][2], terminal emulators, C0 and C1 controls can even be used to execute arbitrary code. You could say these terminal emulators are insecure, and you may well be right, but the fact is they exist.

[1] See for example page 211 of https://static.zumasys.com/zumasys/atfiles/manuals/at7/AccuT... which documents the ESC STX [2] Also the APC C1 control can make Kermit run arbitrary commands, if you've executed "SET APC UNCHECKED" (which is not the default setting) – see http://www.kermitproject.org/onlinebooks/usingckermit3e.pdf page numbered 300 (page 310 of PDF)

Re: The Beauty of Unix Pipelines

#314

Post by michaelcampbell »

jcranmer wrote: post #38
gorgoiler wrote: post #21

Pipes are wonderful! In my opinion you can’t extol them by themselves. One has to bask in a fuller set of features that are so much greater than the sum of their parts, to feel the warmth of Unix: (1) everything is text (2) everything (ish) is a file (3) including pipes and fds (4) every piece of software is accessible as a file, invoked at the command line (5) ...with local arguments (6) ...and persistent globals in…

> (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…

Ah yes, perfect is the enemy of the good.

Re: The Beauty of Unix Pipelines

#315

Post by enriquto »

necrotic_comp wrote: post #309
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.

At Goldman, the internal language Slang has spaces in variable names. It's insane at first glance and I got into an argument with my manager about why in the world this was acceptable, and he could give me no other answer than "this is the way it is". But when you realize that space isn't a valid separator between token, seeing things like "Class to Pull Info From Database::Extractor Tool" actually becomes much easie…

> I was on your side until I tried it, but it can actually be quite useful, esp. if everything is consistent.

On my side? You cannot imagine how extreme one can be... If I had my way, programming languages would only allow single-letter variables and space would be the multiplication operator.

Re: The Beauty of Unix Pipelines

#316

Post by globular-toast »

JadeNB wrote: post #2

What does it mean to say that the video shows "Kernighan being a complete chad"?

According to Urban Dictionary:

"chad 1. Residue of faecal matter situated between arse cheeks after incomplete wiping and can spread to balls."

I have no idea why the author decided to use that term.

There is a related term "Chad" (capital C) which invokes the image of a man who is attractive to women. Again, I have no idea why the author decided to use that term.

Re: The Beauty of Unix Pipelines

#318

Post by cnity »

CalmStorm wrote: post #68
AnimalMuppet wrote: post #43

Earlier quoted context omitted.

Could you be more specific? I don't get it.

In Unix: a; b # Execute command b after a. The result of a is not used by b. In Haskell: a >> b # Run function b after a. The result of a is not used by b. In Unix: a | b # Execute command b after a. The result of a is used by b. In Haskell: a >>= b # Run function b after a. The result of a is used by b.

Nitpick, sort of, but in unix, a | b executes a and b in parallel, not sequentially. This somewhat complicates the analogy with programming. They're more like functions operating on a data stream.

Edit: I might be misinterpreting your use of "execute _after_". You may not mean "after the completion of a" but instead "operating on the results of a, asynchronously" in which case, apologies.

Re: The Beauty of Unix Pipelines

#319

Post by jcranmer »

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.

And note that, all the way in my original argument, I complained that every command used a different way of spelling that changed delimiter character.

Re: The Beauty of Unix Pipelines

#320

Post by majewsky »

ecnahc515 wrote: post #52
ketanmaheshwari wrote: post #6

Unix pipelines are cool and I am all for it. In recent times however, I see that sometimes they are taken too far without realizing that each stage in the pipeline is a process and a debugging overhead in case something goes wrong. A case in point is this pipeline that I came across in the wild: TOKEN=$(kubectl describe secret -n kube-system $(kubectl get secrets -n kube-system | grep default | cut -f1 -d ' ') | grep…

This is a pretty bad example since kubectl can output JSON and using something like `jq` would have made it even simpler.

Better yet, kubectl can take a jsonpath expression to select from the JSON. For example, to just get a name:

  kubectl get something -o jsonpath='{.items[*].metadata.name}'
Post reply on HN