Interesting comment in the header of this site. https://github.com/prithugoswami/personal-website/blob/maste...
The Beauty of Unix Pipelines
161–170 of 388 posts
Re: The Beauty of Unix Pipelines
#162It's ironic that the article ends with Python code. You could have done everything in Python in the first place and it would have probably been much more readable.
But slower
Re: The Beauty of Unix Pipelines
#163Earlier quoted context omitted.
To criticize sh semantics without acknowledging that C was always there when you needed something serious is a bit short sighted. There are two uses of the Unix “api”: [A] Long lived tools for other people to use. [B] Short lived tools one throws together oneself. The fact that most things work most of the time is why the shell works so well for B, and why it is indeed a poor choice for the sort of stable tools desig…
There's a certain irony in responding to criticism of that which you're extolling by saying not to use it. And the only reason I might be pushed down that path is because the task I'm working on happens to involve filenames with spaces in them (without those spaces, the code would work fine!), because spaces are a reasonable thing to put in a filename unless you're on a Unix system.
That's when it's useful to use Perl as a substitute for a portion of or the entire pipeline.
Re: The Beauty of Unix Pipelines
#164Earlier quoted context omitted.
Try doing that in e.g. Make
Try finding out which registry key you need to edit to get something to happen. Some things across different systems have pitfalls as a result of their implementation, or some features have pitfalls. There are half a dozen things I can point to on windows that are worse than the "spaces in filenames". Hell, windows doesn't even support ISO 8601 dates, or times to be properly placed in files. It restricts symbols much…
who said anything about windows?
Re: The Beauty of Unix Pipelines
#165Surprised there is no mention of Doug McIlroy: https://wiki.c2.com/?DougMcIlroy
Re: The Beauty of Unix Pipelines
#166Pipes 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…
> (2) everything (ish) is a file I'm not all that knowledgable about Unix history, but one thing that has always puzzled me was that for whatever reason network connections (generally) aren't files. While I can do: cat to read from a serial device, I've always wondered why I can't do something like: bind /tmp/mysocket 12.34.56.78 80 cat It is weird that so many things in Unix are somehow twisted into files (/dev/fb0?…
Berkeley sockets were kind of bolted on as an afterthought. If the AT&T guys developed them they would probably look a lot more like that.
Re: The Beauty of Unix Pipelines
#167Minor nitpick: It is Unix "pipes" (not pipelines).
Re: The Beauty of Unix Pipelines
#168Earlier quoted context omitted.
> The Macintosh model, on the other hand, is the exact opposite. The system doesn’t deal with character streams. Data files are extremely high level, usually assuming that they are specific to an application. When was the last time you piped the output of one program to another on a Mac? And yet, at least it's possible to have more than one Macintosh application use the same data. Half the world has migrated to web a…
Command-line tools where you glue byte streams are, in spirit, very much like web scraping. Sure, tools can be good or bad, but by design you are going to have ad-hoc input/output formats, and for some tools this is interleaved with presentation/visual stuff (colors, alignment, headers, whitespaces, etc.). In a way web apps are then more alike standard unix stuff, where you parse whatever output you get, hoping that…
> The most reusable web apps are those that offer an API, with JSON/XML data formats where you can easily automate your work, and connect them together.
Sadly these kind are also the most rare.
Re: The Beauty of Unix Pipelines
#169Earlier quoted context omitted.
> (2) everything (ish) is a file I'm not all that knowledgable about Unix history, but one thing that has always puzzled me was that for whatever reason network connections (generally) aren't files. While I can do: cat to read from a serial device, I've always wondered why I can't do something like: bind /tmp/mysocket 12.34.56.78 80 cat It is weird that so many things in Unix are somehow twisted into files (/dev/fb0?…
I think you're just seeing the abstraction fall apart a bit - for weirder devices, I would say they are "accessible" via a file, but you likely can't interact with it without special tools/syscalls/ioctls. For example, cat'ing your serial connection won't always work, occasionally you'll need to configure the serial device or tty settings first and things can get pretty messy. That's why programs like `minicom` exist…
Theoretically it would work if the devices were exposed as directories, not files (which is basically what /proc actually does for most things).
/dev/ttyS0 should really be /dev/ttyS0/{data, ctr, baud, parity, stopbits, startbits} (probably a bunch I'm forgetting).
Re: The Beauty of Unix Pipelines
#170Earlier quoted context omitted.
I am firmly in the "ugh" camp. I strongly suspect that the fawning that occurs over pipelines is because of sentimentality more than practicality. Extracting information from text using a regular expression is fragile. Writing fragile code brings me absolutely no joy as a programmer - unless I am trying to flex my regex skills. If you really look at how pipelines are typically used is: lines are analogous to objects…
If you're having to extract your data using a regex, then the data probably isn't well-formed enough for a shell pipeline. It's doable, but a bad idea. Regex should not be the first hammer you reach for, because it's a scalpel. I recently wanted cpu cores + 1. That could be a single regex. But this is more maintainable, and readable: echo '1 + '"$(grep 'cpu cores' /proc/cpuinfo | tail -n1 | awk -F ':' '{print $2}')"…
That seems overly complicated to me. Can you not just:
grep '^processor' /proc/cpuinfo | wc -l