Live data from Hacker News

Dt: Duck tape for your Unix pipes

dt.plumbing

71–80 of 162 posts

Re: Dt: Duck tape for your Unix pipes

#71
post #56
post #25

Earlier quoted context omitted.

TIL that " duck tape" is actually the correct/original version, and " duct tape" is a modern derivative. I had always assumed it was the other way round, and some people simply don't know what a duct is so they substitute a similar-sounding, more common word.

Sounds like “duck tape” is adhesive fabric tape (maybe water resistant?) and “duct tape” is shiny metal tape for connecting air ducting? And both names are used informally for either or both types of tape by most of the population? And then so many people post “facts” about a clearly fuzzy issue and proceed to argue about who’s “right”. I’m getting real blegg/rube vibes from the whole argument here.

> "Sounds like “duck tape” is adhesive fabric tape (maybe water resistant?) and “duct tape” is shiny metal tape for connecting air ducting? And both names are used informally for either or both types of tape by most of the population?"

This is how I always understood the situation, and then I've recently discovered the issue is further "muddied" by a brand name/trademark "Duck Tape" also, so that's fun...

Re: Dt: Duck tape for your Unix pipes

#72

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.

I’m with you here. Once you get the hang of it you even miss the most awkward pipelines once they’re gone and you’re just passing around single dimensional strings. The memory overhead with sets of objects and their properties vs vanilla strings is significant though and easy to bump up against when working with large data sets. Best to try to keep all of the processing for that dataset in a single pipeline if you ca…

Yeah the memory usage of the pipeline is real. Often using foreach instead to save memory is needed. Or good old fashioned array chunking.

Re: Dt: Duck tape for your Unix pipes

#73
post #38

Earlier quoted context omitted.

What an epic failure by the trademark office. That's as if a company had tried to trademark "Hammer" as a brand name for hammers, and the trademark office just said "Yeah, sure!"

They don’t check trademarks like they (are supposed to) do patents. You want a registration? Here you go. Now someone has to take it to court to see if it stands up.

Some countries do patents the same way. They're called non-examining patent offices.

Re: Dt: Duck tape for your Unix pipes

#74
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.

The painful part of all this is that there were and still are actual record separator and field separator characters in ASCII.

ASCII was perfect for table output. All tools had to do when outputting is use the standard existing characters when no TTY is detected, else use tabs/spaces and newlines.

I always wondered why no one uses the ASCII rs and FS codes.

Re: Dt: Duck tape for your Unix pipes

#76
post #41
post #36

Earlier quoted context omitted.

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

IMO, it's rather embarrassing how rarely they work together without a decent amount of effort. Especially in light of the fact that, e.g., `ls | rm` does work exactly as expected on Windows nowadays.

Re: Dt: Duck tape for your Unix pipes

#77
post #47

Earlier quoted context omitted.

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

> 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.

I think you're misunderstanding how Nushell works. They don't parse outputs, or generate inputs, from/for standard Unix commands. Instead, they implement their own commands with the same names as standard commands, and generate/consume structured data by default, using the same data structures everywhere. There is only a single implementation of those data structures. That's very easy to maintain.

So running `ls` from Nushell does not shell out to the `ls` program on your system, and then try to make sense of its output. It runs a Nushell-internal command that is tailored to the kind of pipelines that Nushell is built around. They already have hundreds such commands implemented and working, and that approach absolutely does scale. Whatever issues may remain, it already works much more reliably than the default Unix tools.

Saying that unstructured text streams are a universal interface is like saying that atoms are a universal construction kit – it's technically correct, but pretty useless in practice.

Re: Dt: Duck tape for your Unix pipes

#78

What do the -- in the documentation mean? Also why does one command use double backslash (\\word) while others only a single one (\word)?

Isn't it the bash double dash[0] that signifies the end of cli options?

[0] https://unix.stackexchange.com/a/11382

Re: Dt: Duck tape for your Unix pipes

#79
post #10

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

Yeah, the examples are focused on dt’s internal state and features. A few real world practical examples of what you can do with it would be much better.

For example I am trying to figure out how I would split each line on a delimiter. I cant figure out what the syntax is

dt [ "," split ] pls prints split

dt [ "," split ] map pls prints stack underflow

I think I could definitely use this if it had better docs and I could figure out how to.

Re: Dt: Duck tape for your Unix pipes

#80
post #69

Earlier quoted context omitted.

Or like "Apple" as a brand name for... nevermind

That's different. Apple as a trademark for a computer (or for a record company) is fine. Apple as a trademark for apples... not so.

Just that the "difference" stops when they now sue any grocery related company having anything like an apple in their logos..
Post reply on HN