You sir, have made my morning(I mean afternoon).
Thanks!
Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"
31–40 of 112 posts
Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"
#32Nope, can't say I've needed to do any 2D pattern matching on the UNIX command line, ever. Sure back in age of dinosaurs when command line was being used for 2D graphics this may have been useful, but ... we have actual GUI interfaces to do that now.
What about source code? Like Pike, I think that it's a little bit nonsensical that
foo(shortArg1, shortarg2, shortArg3);
foo(longArg1,
methodCall().stuff(),
evenMoreComplicatedStuff);
Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"
#33The real problem is that Unix commands produce flat text output without any information about how to parse that text back into structured data. Any user who wants the structured version of the data has to parse it themselves, but these parsers are ad hoc and incomplete by their very nature. People praise perl, sed, awk, cut, etc. for being good at text processing. But the only reason they need these text-processing t…
Actually I've been considering/dreaming about a thing like this for a long while now (ever since I got started with jQuery and discovered how smooth I could sail through the DOM with it). The idea I came up with (I'm most likely not the first to think of it, so tell me if someone already implemented it) is a sort of JavaScript shell for *nix that'd work similar to jQuery: passing along (collections of) JavaScript objects with properties and functions.
e.g.:
var sum = 0;
$("~").ls({"type": "file", "size": ">1M"}).each(function () {sum += $(this).size("mb");});
$.echo("total size of home directory: %d MB", sum);Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"
#34Take this sort of thinking to the limit, and you end up with a unification of a programming language with the OS. Lisp Machines and some of the first instances of Smalltalk were like this. (Smalltalk used to be an OS.) In this case, you don't ever parse text output from your shell tools. You just code directly against objects and streams and collections of objects.
Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"
#35Nope, can't say I've needed to do any 2D pattern matching on the UNIX command line, ever. Sure back in age of dinosaurs when command line was being used for 2D graphics this may have been useful, but ... we have actual GUI interfaces to do that now.
What are you talking about? Graphics have nothing to do with it.
Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"
#36The real problem is that Unix commands produce flat text output without any information about how to parse that text back into structured data. Any user who wants the structured version of the data has to parse it themselves, but these parsers are ad hoc and incomplete by their very nature. People praise perl, sed, awk, cut, etc. for being good at text processing. But the only reason they need these text-processing t…
The real problem is that Unix commands produce flat text output without any information about how to parse that text back into structured data. Any user who wants the structured version of the data has to parse it themselves, but these parsers are ad hoc and incomplete by their very nature.
There are a variety of serialization schemes that are quite easy to parse and would be suitable for the output of most Unix command-line tools. BEncode from bittorrent would do nicely, and it's quite easy to parse. JSON would do nicely as well.
Better yet, unify the shell with a virtual machine that is used to implement the OS, and have everything available as 1st class Objects.
Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"
#37Take this sort of thinking to the limit, and you end up with a unification of a programming language with the OS. Lisp Machines and some of the first instances of Smalltalk were like this. (Smalltalk used to be an OS.) In this case, you don't ever parse text output from your shell tools. You just code directly against objects and streams and collections of objects.
This is the principle behind Microsoft's PowerShell. Everything is .NET objects.
Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"
#38The real problem is that Unix commands produce flat text output without any information about how to parse that text back into structured data. Any user who wants the structured version of the data has to parse it themselves, but these parsers are ad hoc and incomplete by their very nature. People praise perl, sed, awk, cut, etc. for being good at text processing. But the only reason they need these text-processing t…
Actually I've been considering/dreaming about a thing like this for a long while now (ever since I got started with jQuery and discovered how smooth I could sail through the DOM with it). The idea I came up with (I'm most likely not the first to think of it, so tell me if someone already implemented it) is a sort of JavaScript shell for *nix that'd work similar to jQuery: passing along (collections of) JavaScript obj…
Or, one could write a library of standard parsers and serializers for the Unix tools that would parse and produce known JSON representations of data that could be passed between scripts.
Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"
#39In terms of flexibility, I think this would be a fantastic addition to the tools. Having it be a shell var instead of an argument might be worthwhile - if I have a few stages in a pipeline dealing with the same kind of record, it seems useful to be able to say ( RECORD_PATTERN=somepattern; my | pipe | line | whatever ) rather than my -R somepattern | pipe -R somepattern | line -K somepattern | whatever -R somepattern
It could just be a set of separate tools one could pipe data to.
Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"
#40The real problem is that Unix commands produce flat text output without any information about how to parse that text back into structured data. Any user who wants the structured version of the data has to parse it themselves, but these parsers are ad hoc and incomplete by their very nature. People praise perl, sed, awk, cut, etc. for being good at text processing. But the only reason they need these text-processing t…
Actually I've been considering/dreaming about a thing like this for a long while now (ever since I got started with jQuery and discovered how smooth I could sail through the DOM with it). The idea I came up with (I'm most likely not the first to think of it, so tell me if someone already implemented it) is a sort of JavaScript shell for *nix that'd work similar to jQuery: passing along (collections of) JavaScript obj…
Powershell on Windows does something like what you want:
PS C:\Some Directory $sum = 0
PS C:\Some Directory dir | where { $_Length -gt 1MB } | %{ $sum += $_.Length }