[HN Gopher] The Beauty of Unix Pipelines (2020)
___________________________________________________________________
The Beauty of Unix Pipelines (2020)
Author : ddtaylor
Score : 34 points
Date : 2022-06-04 04:45 UTC (18 hours ago)
(HTM) web link (prithu.dev)
(TXT) w3m dump (prithu.dev)
| ogogmad wrote:
| If "programs ought to do one thing and do it well", then why
| aren't they just library functions in a scripting language?
| Scripting languages can probably do the same things (if given
| minor syntax improvements, see Xonsh) in one line as well, and
| scale to have more complicated logic if needed. I still don't see
| the beauty.
| dahart wrote:
| Why would having them just be library functions make it better?
| (I don't disagree, just curious what you're thinking.) The
| actual differences between pipeable programs and library
| functions might be hard to pin down concretely. Btw do you use
| unix & pipes a lot, or not much?
|
| Here are a few thoughts, maybe helpful or maybe not. Part of
| the beauty of pipes and simple lego-brick programs is the
| complete integration with the operating system, and more
| specifically the file system. Being able not just to write your
| state to a file, but furthermore having that be the default
| mode of operation is pretty powerful, especially combined with
| special files. Writing to a file in a scripting language that's
| not a shell is usually easy, but not the default, and would be
| cumbersome to do at every step. Part of do one thing well is to
| keep the shell DRY - don't add sorting or searching or
| filtering functionality to another program if you can already
| use grep or sort or sed. Done right, this helps people stay
| fluent with a small number of tools. Another implicit benefit
| of the unix philosophy that wasn't mentioned here, but does go
| hand-in-hand with pipes and small-good tools, is the idea to
| process and work with human readable text files.
|
| One way to look at unix beauty is to do some command line data
| analysis. I like the general philosophy of data exploring with
| piped commands for one-off and small projects. Sometimes more
| focused tools are needed, but most of the time perhaps you can
| get away with unix tools.
| https://en.wikibooks.org/wiki/Ad_Hoc_Data_Analysis_From_The_...
| winety wrote:
| > ...then why aren't they just library functions in a scripting
| language?
|
| I'd say they basically are. What's the difference between
| Python's sort and (let's say) Bash's sort? In Python I call
| sort to order a data structure like a list. In Bash I do the
| same, but on a different data structure. The crux of the matter
| is probably buried in semantics.
|
| > I still don't see the beauty.
|
| What I like about shell and pipelines is that they allow me to
| easily edit and play with text. I don't need to think about
| opening nor closing files, I don't need to think how to best
| represent the data I'm working with. In minutes I can get the
| information I need and I can move on.
| jdhendrickson wrote:
| I mean... isn't that what is already happening, the shell is
| the scripting language, and compiled binaries that mung text
| are the library functions.
|
| Unix/Unixlike operating systems aren't perfect, but they get
| the job done.
| dkresge wrote:
| Moreover, something rarely mentioned, multiple processes and
| pipes can give you some _free_ parallelism courtesy of the
| scheduler.
| indymike wrote:
| > If "programs ought to do one thing and do it well", then why
| aren't they just library functions in a scripting language?
|
| In many cases, the command line tool is a wrapper for an
| awesome library, and the awesome library has bindings for
| multiple scripting languages. So in many cases, there's a
| command, and a library and yeah, you can import the library
| into your favorite scripting language (or often compiled
| language, too). In the end, you could argue that all languages
| are just an abstraction for system calls anyway.
|
| So why the love for the Unix shell? One line is faster for the
| user than 23 lines. It's the same reason we use compiled
| languages instead of assembly most of the time. The same
| applies to using python of javascript instead of C or rust.
| Less lines of code. Bigger abstractions. Problem is solved and
| the work is done faster.
|
| > I still don't see the beauty.
|
| The whole "collection of small programs that do one thing well"
| thing is just one way to do it, and there are plenty of
| examples of programs that are super successful that don't heed
| that advice in any way at all. In the end, Unix has held up for
| a remarkably long time... seems like there should be a better
| way to do it, but it's hard to argue with Unix success in the
| wild.
| csdvrx wrote:
| It's very nice indeed, but PowerShell pipelines are at another
| level of beauty: think what you could do if instead of just
| STDOUT (and STDERR to be fair) you had data structures with names
|
| On Windows try for the fun it:
|
| Get-ChildItem -Path HKLM:\SYSTEM\ControlSet001\Services\DeviceAss
| ociationService\State\Store\ | Select-String -Pattern Bluetooth
|
| Now look at how it parallelize the request by default, and how it
| returned you several columns of data per line.
|
| Want a regex?
|
| Get-ChildItem -Path HKLM:\SYSTEM\ControlSet001\Services\DeviceAss
| ociationService\State\Store\ | Select-String -Pattern Bluetooth |
| ForEach-Object { $_ -replace 'HK.*-','' -replace ':', ''}
|
| Want a CSV? Add "| ConvertTo-Csv"
|
| Let's do another, to filter only devices (a named property)
|
| Get-PnpDevice -Class 'Bluetooth' -PresentOnly | Where-Object
| HardwareID -match 'DEV_' | Get-PnpDeviceProperty | ConvertTo-Csv
|
| Now I'm learning how to do better things like lambdas on the
| pipeline
|
| PowerShell is weird the first time, but it's so well made it'll
| give you hours and hours of fun :)
___________________________________________________________________
(page generated 2022-06-04 23:00 UTC)