If I can do a slight PG impression, "what problem does this solve?"
Among others, this problem: http://www.dwheeler.com/essays/fixing-unix-linux-filenames.h... find -print0 is a lame hack, and even filenames with spaces (not newlines) are somewhat messy to work with on the Unix shell. Or a little recurring problem I have: How do I grep the output of grep -C (matches showing multiple lines delimited with a "--" line)? I wrote a custom tool to do it, which does the job, but really it w…
Next generation Unix pipe by Alex Larsson
51–60 of 86 posts
Re: Next generation Unix pipe by Alex Larsson
#52Re: Next generation Unix pipe by Alex Larsson
#53I've quickly jotted some thoughts here: http://damnkids.posterous.com/rich-format-unix-pipes Regarding this version, standardizing on a particular transfer format is a bad idea. If history has shown anything, it's that we like to reinvent this stuff and make it more complicated than necessary (see also XDR, ASN.1, XML, etc. :) pretty much on a 5 year cycle or thereabouts. Do the bare minimum design necessary and let…
Having to many different formats is also a problem though, as incompatible formats means you can't combine two apps in a pipepine. The negotiations in dtools is made using a F_GETLK hack with a magic value offset. That approach could easily be extended to support multiple formats.
Similarly, producing a big ecosystem of utilities to go along with it will probably result in a bunch of 1970s style compatibility commands that nobody actually uses any more (say, in 2030).
But feel free to bake a glib-specific serialization in and I'll feel free to pass it up. ;)
Love your fcntl() hack. My kind of hack!
Re: Next generation Unix pipe by Alex Larsson
#54I've quickly jotted some thoughts here: http://damnkids.posterous.com/rich-format-unix-pipes Regarding this version, standardizing on a particular transfer format is a bad idea. If history has shown anything, it's that we like to reinvent this stuff and make it more complicated than necessary (see also XDR, ASN.1, XML, etc. :) pretty much on a 5 year cycle or thereabouts. Do the bare minimum design necessary and let…
Having to many different formats is also a problem though, as incompatible formats means you can't combine two apps in a pipepine. The negotiations in dtools is made using a F_GETLK hack with a magic value offset. That approach could easily be extended to support multiple formats.
Re: Next generation Unix pipe by Alex Larsson
#55"Even something as basic as numerical sorting on a column gets quite complicated." sort -g -k field_num
Re: Next generation Unix pipe by Alex Larsson
#56But I do concede that it has the downside that if the object lacks the properties you want to access, then it might be painful in some cases.
Re: Next generation Unix pipe by Alex Larsson
#57"Even something as basic as numerical sorting on a column gets quite complicated." sort -g -k field_num
Sometimes I feel like POSIX idioms are like the bible to some here: untouchable.
Re: Next generation Unix pipe by Alex Larsson
#58Actually I prefer Powershell's approach to transfer objects, as it is more flexible than standardize in a specific transfer format. But I do concede that it has the downside that if the object lacks the properties you want to access, then it might be painful in some cases.
Re: Next generation Unix pipe by Alex Larsson
#59Earlier quoted context omitted.
> find -print0 is a lame hack, and even filenames with spaces (not newlines) are somewhat messy to work with on the Unix shell. This problem is simply a flaw in sh (and its descendants), other shells handle it much better, see for example Tom Duff's rc shell: http://rc.cat-v.org Also note that Plan 9, the successor to Unix (and which uses the rc shell as its main shell) doesn't even have a find command, find's design…
> This problem is simply a flaw in sh (and its descendants) Indeed, although it's not just sh; if you want to, say, make a table of filenames and some attributes of each file, you're in trouble if the filenames contain spaces (awk, cut, sort don't work as easily) and screwed if they contain newlines. What does Plan 9 use instead of find? > As for your second questions, the answer might be structural regular expressio…
Instead of find, I run /bin/test on a list of files. For anything more complicated than what test can handle, I use Inferno's fs program.†††
† http://swtch.com/cgi-bin/plan9history.cgi?f=1999/0323/port/c...
†† http://a-30.net/inferno/man/4/trfs.html
††† http://www.vitanuova.com/inferno/man/1/fs.html It has a misleading name. It is not a file server.
Re: Next generation Unix pipe by Alex Larsson
#60I've been playing around with a similar idea - using plain JSON as the message format, you can make a set of pipeable command line utilities for manipulating data from many web APIs.
https://github.com/benbernard/RecordStream
I've used it a lot and it's a godsend for a most "record-y" manipulation.