Live data from Hacker News

Dt: Duck tape for your Unix pipes

dt.plumbing

41–50 of 162 posts

Re: Dt: Duck tape for your Unix pipes

#41
post #36
post #30

Earlier quoted context omitted.

The Unix philosophy doesn't dictate any specific data format to interoperate between commands, besides this being data streams, and typically text. Commands are free to interpret these streams however they want, which is why this seems like "hodgepodge", but in no way were tools breaking any sort of promise. FWIW I've been using *nix machines for decades, and very rarely have I had the need to use structured data bet…

> but in no way were tools breaking any sort of promise The Unix philosophy as usually stated includes the rule "write programs that work together". Most Unix commands don't work together in any meaningful sense. For example, `ps | kill` will not terminate all processes, as one might naively expect. I'd say this is a clear violation of both the letter and the spirit of the Unix philosophy.

I mean, neither will `ls | rm`, and a myriad of such combinations if you try them blindly, but it's unreasonable to assume that every combination of commands will work in the simplistic way you expect them to.

Tools like xargs exist to fill that void, and it allows the tools themselves to work independently.

Developing a set of tools from scratch that share a strict design principle is much easier than enabling an ecosystem of purpose-built tools developed over decades by external contributors to interoperate with each other. Leaving the exchange format open is a reason this still works so well today. Or would you rather use XML or whatever format was popular 40 years ago, have to adopt a new format whenever the previous one becomes outdated, and deal with compatibility hell when tools support different versions of the format?

Re: Dt: Duck tape for your Unix pipes

#42
post #17

Title should be > Dt: Duct tape for your Unix pipes ^^^^

Curiously enough, not really, from the post: Excuse me, is it "duct" or "duck" tape? I mean sure, "duct tape" and "duck tape" are both fine. "Duct tape" is the more common name today. The older name is "duck tape" after the duck cloth under the adhesive. As an aside: If you care about such things, make sure to read up on how today's common version became popular. A 51-year-old woman named Vesta Stoudt, mother of 8, m…

The title of the article spells it "duct", and titles should not be editorialized.

Re: Dt: Duck tape for your Unix pipes

#43
post #40
post #26

Earlier quoted context omitted.

That is not what the thing you quoted says, or even correct. All duct tape is made of fabric and it is… well duct tape, so ducts were the intended use case when the name was created. Duct tape has kinda become a general term for all cloth-based tapes though, so you can indeed find duct tape not intended for ducts, but the fact the name was originally “duck tape” has nothing to do with that.

ASHRAE/UMC actually specify tape 'for ducts' to be UL 181A-P/181B-FX [0] which is commonly made of metal foil and not cloth. [0] https://tapeuniversity.com/products/foil-tapes/ul181ap-ul181...

No matter how mundane a random claim posted on HN is, there is always a user with expert knowledge willing and able to respond with a "well actually...", citing incredibly specific details that I've never even tangentially heard about in my entire life until that point.

Re: Dt: Duck tape for your Unix pipes

#44
In my profressional life I have cause to work with Powershell a great deal, and I love the object oriented pipelines that it has.

Being able to filter, sort, or transform properties of the objects passed over makes it much more straightforward to work with than bash et al.

Re: Dt: Duck tape for your Unix pipes

#45

This article links to https://en.wikipedia.org/wiki/Vesta_Stoudt , which links to https://en.m.wikipedia.org/wiki/Cotton_duck , which explains that the word "duck" here comes from the Dutch doek , or "linen canvas".

ISTR from my scout days that "ducking" is a fabric surround at the bottom of tent walls that you tuck under the groundsheet - probably from the same root, I guess - though few online dictionaries seem to have heard of it.

Re: Dt: Duck tape for your Unix pipes

#46
post #28

up: Ultimate Plumber for shell https://github.com/akavel/up

Nice one.

There have been so many nice CLI tools these last 10 years. Quality of life kind of nice. ag/rg, fzf, entr, up, lf...

Go and rust have been appreciated enablers, even though ruby/python/js demonstrated the concepts, with somewhat poor performances and UX.

Re: Dt: Duck tape for your Unix pipes

#47
post #30

Earlier quoted context omitted.

The Unix philosophy doesn't dictate any specific data format to interoperate between commands, besides this being data streams, and typically text. Commands are free to interpret these streams however they want, which is why this seems like "hodgepodge", but in no way were tools breaking any sort of promise. FWIW I've been using *nix machines for decades, and very rarely have I had the need to use structured data bet…

Null separators between fields is structured data. It might just be the simplest that can possibly work (because the null character is outside the normal data range for text, unlike the newline, which demonstrably doesn't work in that sense) but it is structure. A list structure, specifically. The world would be a much happier place if -print0 (or whatever) was universal, but no such luck.

Sure, but the reason it works with any tool is because it's generic and simple. If each tool had to implement anything more sophisticated like a JSON parser and serializer, it would be a nightmare to maintain. Projects like Nushell essentially need to handle every type of output from any command, and every type of input to any command, which is an absurd amount of work, and just not scalable. Subtle changes in this strict contract means that pipelines will break, or just not be well supported[1].

If programs simply input and output unstructured data, it's up to the user to (de)structure this data in any way they need. The loose coupling is a feature, not a bug.

[1]: You can see this in Nushell's issue tracker[2]. I'm not judging the amount of issues, as any healthy OSS project will have many issues, but some of these are critical bugs related to command handling and interop. I'm not blaming the Nushell team either, my hat's off to them, but just pointing out that the nature of the project will inevitably lead to a neverending stream of these types of issues.

[2]: https://github.com/nushell/nushell/issues

Re: Dt: Duck tape for your Unix pipes

#48
I don't really see why existing shell tools and scripting languages are missing, that this project provides. Especially if you consider the expressive range from, say, grep/bc/tr, through sed, through awk, to perl or python.

Re: Dt: Duck tape for your Unix pipes

#49
post #42

Earlier quoted context omitted.

Curiously enough, not really, from the post: Excuse me, is it "duct" or "duck" tape? I mean sure, "duct tape" and "duck tape" are both fine. "Duct tape" is the more common name today. The older name is "duck tape" after the duck cloth under the adhesive. As an aside: If you care about such things, make sure to read up on how today's common version became popular. A 51-year-old woman named Vesta Stoudt, mother of 8, m…

The title of the article spells it "duct", and titles should not be editorialized.

Actually the title as in, html > head > title is "dt: duck tape for your unix pipes".

The poster probably used the HN bookmarklet which sets the title automatically.

Re: Dt: Duck tape for your Unix pipes

#50
post #10

I read the page a few times but I'm still scratching my head. How is this intended to be used?

Presumably it's meant to be used when you're writing a shell script and you have some problem in front of you that would be trivial to solve in a real programming language and you find yourself saying a sentence starting with "I just wanna…" and rage-googling or asking ChatGPT or whatever.

> you have some problem in front of you that would be trivial to solve in a real programming language

Which is the exact point in time when I solve the problem by using a real programming language.

Post reply on HN