111–120 of 323 posts
https://jabustyerman.com/2017/09/29/auditing-your-r-data-pip...
This basically allows you to tag (wrap) intermediate functions in your pipe, and then inspect the objects generated by that function later.
Earlier quoted context omitted.
Reformatted to be readable: > Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”. > Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input. > Design and build software, e…
Why is this or OP's even necessary? The bullet points are copied directly from the article.
Earlier quoted context omitted.
I disagree - the pipe command is trivial at least to us whom have used linux (or unix) based systems for a long time. But to people who follow her and are rather new to this way of doing things, this could be a good read. Either way, it is nice to be reminded of the unix philosophy about chaining tools together for junior and senior alike. Edit: typo fixes
Fair enough. I'm a little surprised at the response. I didn't expect many people here aren't already intimately familiar with pipes, and for those that aren't *nix users, I'm not sure the content is of interest. I guess being honest around here is the wrong thing.
Imagine being this full of yourself.
Earlier quoted context omitted.
The core critique - that everything is stringly typed - still holds pretty well though. >The receiving and sending processes must use a stream of bytes. Any object more complex than a byte cannot be sent until the object is first transmuted into a string of bytes that the receiving end knows how to reassemble. This means that you can’t send an object and the code for the class definition necessary to implement the ob…
Look at the alternatives though. Would you really want to use something like Spring in shell scripting?
I love the idea of simple things that can be connected in any way. I'm not so much a fan of "everything is a soup of bytes with unspecified encoding and unknown formatting". It's an abstraction that held up quite well, but its starting to show its age.
100% agree. Having to extract information with regular expressions is a waste of time. If the structure of the data was available, you would have type safety / auto-completion. You could even have GUIs to compose programs.
However, how can you ensure the output type of one program matches the input type of another?
I'm probably nitpicking, but if you're using cat to pipe a single file into the sdtin of another program, you most likely don't need the cat in the first place, you can just redirect the file to the process' stdin. Unless, of course, you're actually concatenating multiple files or maybe a file and stdin together. Disclaimer: I do cat-piping myself quite a bit out of habit, so I'm not trying to look down at the author…
I think it's also a grammatical wart of shell syntax. Things going into a command are usually on the left, but piping in a file goes on the right.
Cool, the pipe command must be one of the most essential things in Unix/Linux based systems. I would have loved to see some awesome pipe examples though.
A simple virus scanner in one line of pipe:
https://everythingsysadmin.com/2004/10/whos-infected.html
And a bunch of pipe tricks that are oh so wrong but oh so useful:
Earlier quoted context omitted.
ffmpeg took a different approach (sort of like a single program/system with many command line options). Some say its easier to use (at least easier than gst-launch)
I find the ffmpeg options dizzying whereas the single syntax for gst-launch and parse_bin_from_description is pretty neat. But then I guess you've still got a selection of randomly named properties to discover and correctly set.