You can't invent a standard object format because it's only meaningful for a limited set of applications.
Nonsense. People invent data formats all the time. There's a long path to making something "standard" (whether "de facto" standard or approved by some standards committee) of course, but it can be done. This is how progress works - you have to go out on a limb, try something that may not even work, sometimes something that's so alien to people that they're very resistant to the change. And if it works out, then maybe in a few years it'll start to become popular.
The rest, well, you can sort and display based on fields, but you can do so with awk. With this, you just need to know the name of the field rather than the number of the column. And that's about it.
This is true for very simple data structures. However, this is nevertheless a piece of information about how the data is structured which is not accessible in any way from the data itself. The thing about a "standard object format" is that it doesn't need to mandate how data is stored, just how information about the format of the data is communicated. Bash doesn't tell anyone anything about the format of data that goes between processes. It can't, it doesn't know how. If it wanted to, it'd need cooperation from the programs in question, and it'd need some mutually agreed-upon means of communicating that information.
Let's suppose you had a shell program that did nothing but parse C++ source code for other programs. That's all fine and good, but how does it output the result, such that it's both a complete representation of the source, and an easier form for other tools to work with? Some XML format might be a candidate - though requiring your tools to all handle XML is a fairly steep demand.
General purpose tools now have to convert things to text or create some mapping between generic objects and particular objects. Or you have to implement objects as dictionaries, and just treat the field names as meaningless keys (which they pretty much are).
But in text pipes, you are not just converting data to text at your last step, you're converting back and forth on every step.
If I'm just grokking/etc/passwd or a crontab, that could be perfectly fine - the file format is so mind-numbingly simple that there's not much to think about. Truly extensible file formats, extremely large files, and so on, are a different matter. What if I wanted to apply the pipelining system to a 2GiB numeric matrix? Or audio data and/or video data that I want to process and encode?
The answer is, of course, that this sort of thing can be done, and in some cases presently is done with traditional pipelines. Behind the scenes, for instance, mkisofs may be piped to cdrecord, or mp3 decoding may be piped to ogg encoding - this stuff is used and does work. I would characterize the advantages of an OO system in this case as follows:
1: Data type checking, and autoconversion: Let's suppose you did something stupid and passed raw MP3 data to a program expecting only uncompressed WAV data. Most likely the receiving program will quickly realize the incoming data is not a RIFF format, let alone a WAV file, and reject it. But there could be cases where this isn't so easy. Suppose you're passing a buffer of numeric values - single precision floats - to a program expecting double-precision floats in a different byte order. There's no way to catch that. But if the sending program can communicate about the format it's providing, and the receiving program can communicate about the kind of data it's expecting, then the shell can act as an intermediary - implementing a consistent set of rules for what to convert and how, when to present the user with a warning or error message, and so on. If you did something really stupid, like sending MP3 data to a program expecting a text file, the request would be rejected. MP3 data isn't t
Text is only universal because we've made it universal.
Not quite. Text is universal by virtue of it being a stream of bytes, and byte streams are universal in that almost all current computer architectures, networks, storage devices and other devices handle byte streams. In that regard, text isn't just universal in that all programs that you can pipe together in a shell can handle it, but also since you can read it from disk, store it to disk, send/receive it over a network or even send it over an RS232 link, if you so wish.
There is, however, no universally agreed syntax for "objects". Sure, there have been attempts, but I doubt any of them will succeed, maybe ever. Different systems have so vastly different opinions of what an object is, and I believe that is how it should be, because if all systems would have to have the same idea of an object, you would be locking them into a predefined design pattern, and innovation might decrease. I don't know if maybe people said the same thing about bytes in the 50s and 60s, so I wouldn't bet my prediction will turn out to be correct, though.
Well, let me ask you this: why not invent one?
For sure, I understand that people the world over aren't going to embrace a new system like that overnight. But people who use a shell who uses that kind of system would be fine with it. People write modules for Perl, Python, Ruby, etc. all the time - each of those is a scripting language with its own ideas about how to store objects. Do people feel "locked in" by Perl? I'm sure some do - but a lot of people are quite happy with Perl, and the CPAN has all kinds of code (Perl code and binary modules) that are good in nothing but Perl.
Also consider this: once you make a data structure transparent in one way, it is easier to make it accessible in other environments, too. For instance you could say "here's a binary data file. It has a matrix in it" and people would get nowhere - or you could say "here's a binary data file. Its dimensions are (m) by (n), it's stored in column-major format, IEEE double-precision, little endian format, it's not a sparse matrix, and the numeric data starts at offset (x)." - a live object providing that information would make a very convenient starting point for importing the data into Perl, Python, or any other scripting language.
And text isn't "human-readable"
Heh, that's one of the weirder statements I've seen as of late. Kind of like saying that you can't "speak" in a telephone, it's just a PCM stream anyway. Call me weird, but I'd argue that text is human readable by definition. I do (kind of) see your point, though, but I don't agree. Text is always human readable, because it has such an internal structure that makes it human readable with an extremely simple and universally standardized (except for charset) algorithm. If you just have an "object", though, there's no universal algorithm for turning it into a visual structure. Usually, each object class even has its own such algorithm, which isn't usually reversible (unlike text), and not every class even does. To begin with, there is, as I wrote above, no guarantee of any sort that an object is even slightly serializable.
Not that I think that you're wrong in every possible way. I definitely think that an object-oriented shell may have its virtues, but it's never going to work outside its own VM. Text is universal, since you can send it anywhere and receive it from anywhere. That "anywhere" includes a human, too.
My point is that binary "text" is readable specifically because we've established conventions and provided tools that make it readable. If you do the same for a binary format, the same will be true for that binary format.
You can say that some live objects may not be serializable: that is certainly true. Sometimes they're too ephemeral for that, too specific to current operating informat
"Data is structured (or information about the structure of the data is communicated) using mechanisms that are respected by all tools involved."
But it's a plain fact that not all data is structured. The powershell commands may output and input XML, or whatever it is they do. But not everyone uses XML. Oh, sure, maybe everyone SHOULD use XML. But they don't. It's like Java. If you mandate a monolithic platform, compatability problems go away by definition. Your new problem is to convert everyone to your language of choice. How enticing -- replace computer problems with theological problems.
I've spent a lot of time thinking about object-oriented command shells - this is a wrinkle I've already considered.
It's clear that people aren't going to drop what they're doing and all use one grand unified binary format for all their input and output. For many programs it wouldn't make sense - and there's bound to be some application that would push the limits of that particular format to (or beyond) its limits. For instance, streaming files over the internet demands certain characteristics of files that can't be met by things that aren't designed to be read or written in a strictly serial manner. But all data follows some kind of structure, or else it's meaningless. It's a fundamental and unavoidable requirement of data storage on computers.
If you go back to Electronic Arts' original 1985 "IFF" format spec, you'll find a description of their quaint (but noble) ambition - to create a file format that would be respected system-wide. It was to be the one format, and all the things we take for granted today were to be implemented using it - and every new file format would fit into the scheme. That was the idea. I understand it even had a nice little run on Amiga systems. But, yeah, it's a fine example of how mandating one binary format won't work. I don't even want to contemplate stuffing every program's output into the XML format... And today, every nontrivial application defines its own data formats, and they don't follow any particular conventions about how file formats should be identified. Would I propose redefining established formats like JPEG, PNG, MP3, MIDI, XCF, HTML, BLEND, and so on to fit some new scheme? Oh, hell no.
What I propose, instead, is that when a program outputs data in a particular format, it also provides some means of communicating how to interpret that data. The functional equivalent of a Python binding for the data, more or less - if it's a structure, you know what fields it provides, if it's a sequence, you can get elements out of it, if it's text, you know what encoding it's in, if it's a number, you know how to interpret it. So a process may output audio data in MP3, but at the shell level, that data would be an MP3 object. If the receiving process has specialized code for interpreting an MP3 object, it can do things like access the raw data stream (MP3 data), or use the object interface to do things at a higher level - but if it's a naive application that just knows how to deal with the shell-level concept of audio data, or audio data in some compatible format, then there'll be a conversion in there. So the shell mandates a format, but has no delusions of mandating the format.
For backwards compatibility, information like this could be provided statically - if I have a program that I know is going to put out MP3 data, that can be added as an attribute of the program in a kind of masking layer.
Yes, I certainly do want an OO shell to become so widely adopted that people won't mind coming to rely on it and integrate it into everything. My hopes can't be realized otherwise. But I know that between here and there, such a tool would first have to be useful in the current landscape before adoption could occur.
As for your other arguments - - There's not a lot of advantages to having FTP clients as part of the kernel. I think I get what you're saying here,
Exactly. Everything you could ever need to do on Linux, you can do from the shell if you know the commands. Windows? Most programs don't take command line arguments or run in command line mode. That's part of why cmd.exe is so useless. There are no apps that make use of it. There's also the lack of things like grep, sed, etc. in the cmd.exe that make it useless. Bash has all of that, and it has had it for ages. The PowerShell is just MS trying to make an actual useful shell like we have because the old one was so bad. Well, yeah. That's exactly right. MS made a good shell because they didn't have one of their own. They recognized that sysadmin types often liked having access to tools like bash and perl - and so they made something that provides that style of interface, but they gave it sufficient functionality to be able to interface with.NET stuff. That alone makes it necessarily different from traditional Unix shells.
Whether the result is good or not is a matter of opinion. As a Unix user I find some of their decisions distasteful, but I can understand their reasons for making the decisions they did. (The verbose command names, for instance, probably help internationalization) - but I think the direction they've gone is a smart one. They've taken the Unix philosophy of small tools that work well in combination, and extended it so it can work sensibly with much larger, more complex datatypes. Managing that level of complexity benefits from using a consistent mechanism to represent non-trivial data structures. You could create a "consistent mechanism" any way you like, of course - define IFF tags for all file types on your system, encode everything in XML - whatever - and you could still pass the data over regular interprocess pipes. However, there are some implications to this. First off, when the data format becomes significantly complex, the "human readable" advantages of text formats vanish. Fields become populated with escape characters to avoid the use of delimiter characters, the mass of data becomes too large to sensibly view with a raw dump, (or, if you're passing binary over the channel, it ceases to be "human readable" through a console dump at all), etc. Second, you're passing much more data than you need to, which can get rather wasteful. A shell that knows how to pass structured data can make intelligent decisions about how to pass that data. I think in Powershell the basic idea is that the shell helps to determine the object's lifetime, but the actual hosting of the object is done through an object manager (think CORBA).
I don't think Powershell provides any means to actually stream data. So the equivalent of "primes | head | tail" wouldn't work quite the same. (Actually, 'primes' would have to be written so as to return an object capable of generating primes, rather than as an endless data stream of primes. The shell expects 'primes' to actually finish running before calling 'head') I think it might be better to have a system where structured data can be streamed, so that programs in the pipeline don't have to wait for all the data, just the pieces they want.
Suppose I want to iterate through audio files on the filesystem - get "title" metadata from those that have it, and the length of the audio in time units, format that into a list structure and save it in an environment variable.
If this is all stuff that's part of the file format, this is not a shell programming activity at all. file(1) should be taught about all the fields in/etc/magic and then you can just capture its output and do what you wish with the various fields.
I disagree. file(1) has a very specific task - which is to make a best-guess about a file format based on its contents. If you start expecting it to be actually able to interpret all those file formats - you've got a very large program, now, implementing a lot of functionality that is the proper domain of more specialized tools. No, 'file' should simply be able to tell us what program or library on the system we should talk to if we want to interpret the file. That's where the problem crops up in my example - we have the tools - we can certainly pull out title tags with mp3info - and I expect there are other tools that could do it for other formats. The problem, at a basic level, is that these tools don't even have a common interface. It could be sufficient to say "call mp3info for this file, call sox for this file", etc - but you'd also need to supply the proper calling format and the means to parse the output to get the info you want.
This, I contend, is where an object-oriented interface is useful. You say "I want the title field from this audio file", and the shell 1: Determines the format of the file. I'd like to have that information stored in a file's extended attributes - but files lacking that (files served over NFS or off a CD-ROM, or files on systems where people just don't want a bunch of Xattr's floating around for whatever reason) could provide the information in the file extension (UGH) or using file(1) magic. 2: Find the code that tells the shell how to deal with the file. For an OO shell this would likely be a file format handling library - an interface to pre-existing utility libraries, written to work nicely with the OO shell. This library would need to provide various common interfaces to the files in question (for instance, provide a method to decode compressed audio, or tell the shell that a WAVE file is also a type of RIFF file) and provide more specific interfaces to things like format-specific (or even file-specific) data fields. 3: Call the library, making the specified requests.
The specific advantage this provides over traditional shells is that the OO shell can provide domain-specific help in obtaining the correct result. It would be possible, for instance, to have one command-line program to deal with each distinct audio format, and give them very similar interfaces, but then the script writer must take care to call the correct one for each file. It would be possible to create a master audio tool like "sox", but also give it plugin support and add plugins for all relevant file formats - but this just solves one particular case. Do we do the same for all image formats? All video formats? I think that kind of framework would be a good addition to the shell.
the OO solution would be to ask each file for this information.
I'm neither a fan of OO nor a fan of executable data that may have come off-host, but to each his own. In the case of file types, I am a fan of teaching file(1) about the format and letting it do all the messy work. Do one thing and do it well is ancient Unix wisdom more ignored than followed now-a-days, but this kind of stuff is what that program was designed to do. I do believe it is an utter mistake to judge file types by extensions.
You misunderstand, I think. Your MP3 files are not executable. However, the shell does provide an executable interface to them through format-specific libraries. So you really jus
In what sense is Monad's pipeline communication format "application-specific"? It can deal with any.NET object. If you had an object with a field called "Title" that had a value "Foozle", you could access that any way you like. It's not application-specific. You want a human-readable form? "Title : Foozle" pretty much does it.:)
Using objects is a very bad idea because the object itself is application specific. I don't know why everyone is acting like this Powershell interacting with objects is so new. I am dealing with the WebLogic Scripting Tool (WLST) these days which is a Jython interface to a bunch of Java APIs. I'm interacting with objects from a scripting language, and it totally sucks because my scripts don't work from one version to the next. This problem can still occur with UNIX: if you can the format of your text, your scripts are going to break. However, the very act of having to convert data to text makes you *think* about how that should be represented. It's a barrier between the internals of your application and the external world. If you expose your internal objects directly to scripts, then any internal changes you make are going to break scripts. Believe me, those internals change a heck of a lot more often than you would like them to. If you don't allow them to, then you unnecessarily burden your code with backward-compatibility problems, which is exactly what got MS' code into such a horrible state.
The new bit is that this isn't just a new scripting language or programming language, it's designed for interactive sessions, too. It's a tool that could be used equivalently to a Unix command shell - a general-purpose CLI. By contrast, scripting languages usually have their own "program state" of variables and whatnot, while files and outside programs are considered foreign territory in the language's syntax. A general-purpose CLI on the other hand, is a language in which the filesystem and outside executables is part of the program state. Executables on the path serve rougly the same purpose in Bash as Python modules do on the Python module path (though you don't have to 'import' them, of course) - it's your set of tools for that language.
As for changing internals: the same can happen with text-based tools, too. In fact, it has already. I can't tell you how frustrating I find it to deal with the disparities between Solaris tools and the equivalent GNU ones - I prefer the GNU tools because I'm more accustomed to them and I think the changes they provide help to deal with a wider range of problems - but the change from one version of 'find' to another, for instance, requires the use of a different set of command line switches and different text-processing logic as a result. Things change, no matter what underlying technology you use. Stabilizing one's interfaces is a problem that must be solved regardless of whether you're streaming text or passing objects. You could standardize your field-delimiter syntax and still you'd need to stabilize your field order. (Hence,/etc/passwd still has a password field even though no one uses it these days.) You could use a higher-level metaformat like XML and still you'd need to stabilize the format and tagging of the important fields, or you will hit the same compatibility that you cite - which are the result of sloppy API stabilization in object interfaces.
And while specific object classes may be application-specific, the means to see what they provide is not. As with Python, you can tell what all the methods and attributes of an object are.
As for the separate output step: As I said, I'd prefer a more elegant solution. But here's the thing: along each step of a command chain, you want that data to be easy to process. It's just at the last step that you want it to be easy to read. By using structured data, the intermediate steps are some level of compromise (because - guess w
True - but if you look at the shell they've cooked up, maybe they didn't do so poorly after all. There's a lot of great ideas in that thing.
I take it you haven't installed it and tried using it yet? Um... I'll get back to you on that.:D
I know someone mentioned the thing is bloody slow - any other reactions to the thing?
Right now, mostly I appreciate the idea of this thing - what it's capable of and what it's striving to accomplish. I think it's a good idea. Would it be my shell of choice? Yeeg, I don't know about that, the commands are all really long and every example command from the docs is full of scary Windows-isms... I just think "complacent faith in Bourne Shell tradition" isn't the right reaction to this thing. I think it has a lot more potential than that.
it seems like when it comes to the CLI people are content to let it rot. It hasn't "rotted", but it has been sufficiently powerful for several decades now that there aren't many features that need to be added. My favorite hack of the 80's was writing a BASIC interpreter in Korn Shell script with floating point math, gosub/return, single step, pause/continue, full line curses line editing and what not. It was still a Unix style program. It had a small helper program that did the parsing and evaluation of arithmetic expressions and used ed(1) as an coprocess for program storage. It only took a couple of days to code up too. Hacks are fun and all - I thought it was neat when someone implemented Tetris using the "Zork" runtime engine - but I'm less interested in the theoretical capabilities of a shell than in the actual, useful set of features that the shell provides to help me solve problems better.
Let me give an example: one that I contend could be made easier to handle by using a "modernized" and object-oriented command shell. Suppose I want to iterate through audio files on the filesystem - get "title" metadata from those that have it, and the length of the audio in time units, format that into a list structure and save it in an environment variable. Now, with bash, I'd either need one command capable of doing this task with each of the various audio datatypes on my hard disk, or else I'd need to switch between the various file types and run the appropriate command. Now, object-oriented shells won't magically solve all our problems - for instance, if an object for some reason decides to call its "title" field something else - or if a format doesn't have those fields (C64 SID files might have a runtime field - but that was added as an extension, so maybe not) - but the OO solution would be to ask each file for this information.
> $data = for f in (find/audio); do append_output (($f -title), ($f -time)); done
Presumably that would return some nil objects in one or both columns depending on what files are processed. But that's the general idea. And then I'd also like to be able to do this:
>./data_list = $data
Seems like a nice idea to me.
The Z-shell has had dynamic loading of extensions for about 10 years now. I suppose someone could have added GUI extensions that way. Maybe they have, I haven't checked on their development in a long time. Basic textual zsh works perfectly for me. Interesting. Perhaps you could enlighten me a bit as to what these zsh extensions can do? As I said I have this project that's been mulling around in my head for a few years now, for a Linux shell with similar capabilities to Powershell - and in order to justify that work and to direct in sensibly I want to have a better understanding of other shells and operating environments, what they have to offer and what went wrong. I believe in the ideas I'm advocating here, but I also know I can't take them for granted - if I fail to adequately understand Unix then I, too, am likely to reinvent it badly.
I would say I am skeptical of what a zsh extension can accomplish. Sure, a shell extension can add new functions to a shell, but how does that help with the problem of improving command pipelines? How does that help me not to forget to account for the possibility that "find" could return filenames with whitespace in them, or that a field in a character-delimited file could contain the delimiter? Or if it doesn't do that, what does it do?
Glad to see though that Microsoft Windows is finally catching up to old technology in this area. Whether they've "caught up" or "caught us snoozing and lapped us" is a matter of preference, I suppose. I think it also depends on how nice the shell is to actually use. I find the high degree of verbosity in the command naming rather annoying, actually - I suppose that probably helps with L10N but I am used to CLIs being rather more compact. But in terms of functionality they've provided something that I have a strong desire to see realized on Linux.
Text is universal, though, and it lets you have a single means of output for simpler programs. Want to read the results immediately? Just call the program. Want to save the results? Dump them to a file to review later. Text is only universal because we've made it universal. This is the same idea behind XML - it's mainly useful because it's recognized. And text isn't "human-readable" - it's binary just like everything else. It just happens that the process of displaying it is rather simple and the programs to do that are already out there.
If you look at Powershell, they've got the "read immediately" process down - commands like "Format-Table" come to mind. Yeah, big deal, right? It's what PERL was born to do. But nevertheless - if you run a command and it generates an object, a meaningful printed representation of that data appears on the console. If you want it to look nicer, there are commands to format the output. I think the shell would be better if the user didn't need to handle that step explicitly - I have some ideas for how that could be done. (I am very interested in writing a Linux shell with these kinds of capabilities.)
This makes it trivially easy for programmers to modify the output, or for the users to use it in unexpected ways. It means we don't need a separate program to convert binary data to a human-readable form first. From my perspective you've got it backwards. Every single program in a pipeline chain is burdened with the job of converting "human-readable" data to a useful, processable form - and then back to text again for the next chump in the line. So maybe you save one step, because you don't need to reformat the output of your last command - but you've added on two steps for every command in the chain (minus one, for the first) - and when programs start to get even moderately outside the realm of the common, everyday stuff, the user starts having to deal with those processes themselves.
Complex datatypes in a shell are only good if you're using a set of languages that can deal with the same objects. With Unix, not all your languages have a concept such as an object -- not even a struct. Even then, you need a human-readable form for them, even if they're converted at the user's request.
As long as Monad has that, it's probably decent. But that's going to be application-specific. True, that is a problem. Not so much the languages' limitations in handling objects - that's just syntax. You can write object-oriented code in C if you feel like it, and certainly C can interface with object managers like CORBA - it just wouldn't be especially fun. It's more the problem of having a common communication format - that's a hard sell because people don't think they need it, and it's a bit of a tall order to mandate something like that.
In what sense is Monad's pipeline communication format "application-specific"? It can deal with any.NET object. If you had an object with a field called "Title" that had a value "Foozle", you could access that any way you like. It's not application-specific. You want a human-readable form? "Title : Foozle" pretty much does it.:)
The shell is a text interface, if I want OOP I can call a different scripting language for every day of the week and then some.
What's to understand here? Yeah, but how many of them are actually shells? Good shells? What's involved in running Pine from within a Python interactive session?
And then, here's my favorite bit - suppose you have code in Python that does some processing for you and generates some data - maybe even a live object - you want to pipe it out to a Ruby script. If you have an object-oriented shell you can do that shit, no problem. If you have a text-oriented shell, it depends a lot on how complex the data is.
it treats piped arguments as objects instead of strings, Psh lets programs access the data directly, instead of having to manipulate large amounts of textual data with tools such as grep or PERL.
Then they have absolutely no idea about what they are doing. The one big advantage in using pipes is that any application can handle text data.
Let me give one example: I use the sort command all the time, it sorts data by lines of text, lines are compared according to criteria passed in command options.
Now, imagine if it depended on binary objects. For every sort operation one would have to write a comparison function to decide which object should come before the other. Writing a special function would mean declaring some form of callback, or maybe some people would call it a closure, whatever. And so on.
Here's one simple command I use when a disk starts getting full to see which directory is the data hog: du -x / | sort -nr > mem.txt & What this command does is check the disk usage (du command) in the root directory (/) without looking at symbolic links to other disks (-x option). The result is piped to the sort function, where it's sorted by the numeric value of the first column in reverse order (-nr option). The sorted result is sent to a file named mem.txt. Since checking the whole disk may take some time, it's done in the background (& command). After it finishes, I have a file with the size of each directory in the disk, one line per directory, ordered by size, larger directories first.
See how powerful it is, having data represented as text? Try writing this line as a Powershell script.
Another advantage of having data in text format is that you can test it using the keyboard and screen very easily, no need to run a special debugger.
Instead of trying to reinvent Unix poorly, Microsoft would do a favor to its customers if they accepted Unix is a mighty fine OS and adopted without shame its best features.
I strongly disagree with most of what you've said. Here's why.
The supposed "ease" of dealing with text is an illusion - it's a fallacy that's built out of 1: the fact that textual formats are usually organized such that we humans can read them if we send the data out to a console 2: the fact that Unix types have built up a formidable array of text-wrangling utilities to deal with these problems 3: a general assumption that the reading and writing of formats passed between processes won't pose any real challenge to process.
The relative "ease" of text is negated if three corresponding conditions are met in a shell dealing in structured data: 1: Data is structured (or information about the structure of the data is communicated) using mechanisms that are respected by all tools involved. (In other words, there's some kind of Lengua Franca for the structured data -.NET provides this, of course. Similar technologies could provide the same thing on Linux. It's a tall order, mainly because of all the programs in the world that are written for naive assumptions about the shell environment...) 2: The structured data that is used in inter-process pipelines is given suitable (preferably interactive) display methods 3: An appropriate set of data handling tools are introduced, generic enough to work for most problems and powerful enough to be effective.
The problem with textual formats for structured data is that there will always appear ways that you can do it wrong. For instance, what if a field contains the character (or set of characters) you're expecting to use to delimit the fields? Well, that's why find has a -print0 option, isn't it? Now, what if the field could contain null bytes, too? Then maybe you use escape characters - and the process of reading in the output from the previous command starts to become a more complicated parsing problem.
You cite how easy it is to sort based on a field (and, to extend the exam
"Those who fail to learn the lessons of Unix are doomed to re-invent it. Poorly." -- Forgot who said it. True - but if you look at the shell they've cooked up, maybe they didn't do so poorly after all. There's a lot of great ideas in that thing.
has microsoft submitted to linux and unix? we have had a "power shell" for a few decades now.. You sure about that? I think we have crusty old 1970s shells with a veneer of tab-completion and command history added for convenience. I would really like to see that situation change. I like the CLI and I think it's a powerful way to work - if the shell is up to the task. CLI shells ought to be able to, for instance, access the GUI (if any), as well as interact with running applications. These tasks can technically be done with just about any shell - but only in the sense that a program that runs under the shell can do some task and report back information to the shell environment - and the ability to do that is limited by what data types the shell can handle. Bash can handle one datatype, basically - text. It can't handle structured data, it doesn't really support binary data or numbers, let alone live objects you could interact with. I think this is a source of a lot of busywork in traditional shells - you run a program that, say, prints out numeric data from a matrix file, then to process that data the next program in the chain needs to parse the overall output, convert the numbers back to binary, and then probably re-format and print them out as text again. It makes no sense.
I really, really want the Linux CLI to be modernized. (Lots of time is spent working on the Linux GUI, but it seems like when it comes to the CLI people are content to let it rot.) I've spent a lot of time trying to figure out how I would go about doing that. I've read a bit about PowerShell - it seems interesting, at least, and promising. For instance: - It can wrangle live.NET objects and complex datatypes - It encourages a unified interface (conventions for command options, etc.) for CLI programs and utilities - It applies these new techniques in conjunction with existing, traditional shell mechanisms, like pipes. - It endeavors to make documentation and general information about commands easier to access
Now, there's also things I don't like so much - for instance, the distinction between "commandlets" and normal commands. (To be fair, this is largely due to the fact that most existing code in the world is written either for a traditional CLI or a GUI - so most code isn't going to know how to deal with a smart CLI anyway. But I think there are better solutions.)
I think it's kind of a drag that Microsoft may now have a better CLI than Linux - but I think that's a situation that can be changed.
Let's see how many people they think they can arrest under... what law? It's probably not within the spirit of the law, but there's probably a local sodomy law or disorderly conduct law that could be "stretched to fit"...
I mean, sure, lots of people made the connection with HAL 9000, but this post actually got the quote right. "Open the pod bay doors" came after the lipreading scene.
I agree in that when I was a college student I wouldn't have liked this sort of thing at all. But on the other hand - the school has internet access for a reason - and that reason isn't so people can download music or movies or games, and nor is it so that people can participate in serving arbitrary content - regardless of whether sharing that content is legitimate. Even though it's a service to other people, to use bittorrent to get, say, a Linux ISO instead of just leeching it - the campus network's purpose isn't to let students provide services to outsiders, it's to facilitate education. If a student could get their Linux ISO by downloading one copy, rather than downloading one copy and uploading two - that gives them the ability to get their data, but uses less of the school's networking resources to do it.
'Course, in practice the way this usually works is that hosts on the campus network that are consuming a disproportionately large amount of bandwidth will be scrutinized. So the first stage of singling people out could have nothing to do with identifying protocols or what it is the protocols are doing - just if you're using a lot of traffic you get noticed. So there are real limits to how stealthy you can be and still do what you want.
Slashdot Mirror
You can't invent a standard object format because it's only meaningful for a limited set of applications.
Nonsense. People invent data formats all the time. There's a long path to making something "standard" (whether "de facto" standard or approved by some standards committee) of course, but it can be done. This is how progress works - you have to go out on a limb, try something that may not even work, sometimes something that's so alien to people that they're very resistant to the change. And if it works out, then maybe in a few years it'll start to become popular.
The rest, well, you can sort and display based on fields, but you can do so with awk. With this, you just need to know the name of the field rather than the number of the column. And that's about it.
This is true for very simple data structures. However, this is nevertheless a piece of information about how the data is structured which is not accessible in any way from the data itself. The thing about a "standard object format" is that it doesn't need to mandate how data is stored, just how information about the format of the data is communicated. Bash doesn't tell anyone anything about the format of data that goes between processes. It can't, it doesn't know how. If it wanted to, it'd need cooperation from the programs in question, and it'd need some mutually agreed-upon means of communicating that information.
Let's suppose you had a shell program that did nothing but parse C++ source code for other programs. That's all fine and good, but how does it output the result, such that it's both a complete representation of the source, and an easier form for other tools to work with? Some XML format might be a candidate - though requiring your tools to all handle XML is a fairly steep demand.
General purpose tools now have to convert things to text or create some mapping between generic objects and particular objects. Or you have to implement objects as dictionaries, and just treat the field names as meaningless keys (which they pretty much are).
But in text pipes, you are not just converting data to text at your last step, you're converting back and forth on every step.
/etc/passwd or a crontab, that could be perfectly fine - the file format is so mind-numbingly simple that there's not much to think about. Truly extensible file formats, extremely large files, and so on, are a different matter. What if I wanted to apply the pipelining system to a 2GiB numeric matrix? Or audio data and/or video data that I want to process and encode?
If I'm just grokking
The answer is, of course, that this sort of thing can be done, and in some cases presently is done with traditional pipelines. Behind the scenes, for instance, mkisofs may be piped to cdrecord, or mp3 decoding may be piped to ogg encoding - this stuff is used and does work. I would characterize the advantages of an OO system in this case as follows:
1: Data type checking, and autoconversion: Let's suppose you did something stupid and passed raw MP3 data to a program expecting only uncompressed WAV data. Most likely the receiving program will quickly realize the incoming data is not a RIFF format, let alone a WAV file, and reject it. But there could be cases where this isn't so easy. Suppose you're passing a buffer of numeric values - single precision floats - to a program expecting double-precision floats in a different byte order. There's no way to catch that. But if the sending program can communicate about the format it's providing, and the receiving program can communicate about the kind of data it's expecting, then the shell can act as an intermediary - implementing a consistent set of rules for what to convert and how, when to present the user with a warning or error message, and so on. If you did something really stupid, like sending MP3 data to a program expecting a text file, the request would be rejected. MP3 data isn't t
Not quite. Text is universal by virtue of it being a stream of bytes, and byte streams are universal in that almost all current computer architectures, networks, storage devices and other devices handle byte streams. In that regard, text isn't just universal in that all programs that you can pipe together in a shell can handle it, but also since you can read it from disk, store it to disk, send/receive it over a network or even send it over an RS232 link, if you so wish.
There is, however, no universally agreed syntax for "objects". Sure, there have been attempts, but I doubt any of them will succeed, maybe ever. Different systems have so vastly different opinions of what an object is, and I believe that is how it should be, because if all systems would have to have the same idea of an object, you would be locking them into a predefined design pattern, and innovation might decrease. I don't know if maybe people said the same thing about bytes in the 50s and 60s, so I wouldn't bet my prediction will turn out to be correct, though.
Well, let me ask you this: why not invent one?
For sure, I understand that people the world over aren't going to embrace a new system like that overnight. But people who use a shell who uses that kind of system would be fine with it. People write modules for Perl, Python, Ruby, etc. all the time - each of those is a scripting language with its own ideas about how to store objects. Do people feel "locked in" by Perl? I'm sure some do - but a lot of people are quite happy with Perl, and the CPAN has all kinds of code (Perl code and binary modules) that are good in nothing but Perl.
Also consider this: once you make a data structure transparent in one way, it is easier to make it accessible in other environments, too. For instance you could say "here's a binary data file. It has a matrix in it" and people would get nowhere - or you could say "here's a binary data file. Its dimensions are (m) by (n), it's stored in column-major format, IEEE double-precision, little endian format, it's not a sparse matrix, and the numeric data starts at offset (x)." - a live object providing that information would make a very convenient starting point for importing the data into Perl, Python, or any other scripting language.
Heh, that's one of the weirder statements I've seen as of late. Kind of like saying that you can't "speak" in a telephone, it's just a PCM stream anyway. Call me weird, but I'd argue that text is human readable by definition. I do (kind of) see your point, though, but I don't agree. Text is always human readable, because it has such an internal structure that makes it human readable with an extremely simple and universally standardized (except for charset) algorithm. If you just have an "object", though, there's no universal algorithm for turning it into a visual structure. Usually, each object class even has its own such algorithm, which isn't usually reversible (unlike text), and not every class even does. To begin with, there is, as I wrote above, no guarantee of any sort that an object is even slightly serializable.
Not that I think that you're wrong in every possible way. I definitely think that an object-oriented shell may have its virtues, but it's never going to work outside its own VM. Text is universal, since you can send it anywhere and receive it from anywhere. That "anywhere" includes a human, too.
My point is that binary "text" is readable specifically because we've established conventions and provided tools that make it readable. If you do the same for a binary format, the same will be true for that binary format.
You can say that some live objects may not be serializable: that is certainly true. Sometimes they're too ephemeral for that, too specific to current operating informat
"Data is structured (or information about the structure of the data is communicated) using mechanisms that are respected by all tools involved."
But it's a plain fact that not all data is structured. The powershell commands may output and input XML, or whatever it is they do. But not everyone uses XML. Oh, sure, maybe everyone SHOULD use XML. But they don't. It's like Java. If you mandate a monolithic platform, compatability problems go away by definition. Your new problem is to convert everyone to your language of choice. How enticing -- replace computer problems with theological problems.
I've spent a lot of time thinking about object-oriented command shells - this is a wrinkle I've already considered.
It's clear that people aren't going to drop what they're doing and all use one grand unified binary format for all their input and output. For many programs it wouldn't make sense - and there's bound to be some application that would push the limits of that particular format to (or beyond) its limits. For instance, streaming files over the internet demands certain characteristics of files that can't be met by things that aren't designed to be read or written in a strictly serial manner. But all data follows some kind of structure, or else it's meaningless. It's a fundamental and unavoidable requirement of data storage on computers.
If you go back to Electronic Arts' original 1985 "IFF" format spec, you'll find a description of their quaint (but noble) ambition - to create a file format that would be respected system-wide. It was to be the one format, and all the things we take for granted today were to be implemented using it - and every new file format would fit into the scheme. That was the idea. I understand it even had a nice little run on Amiga systems. But, yeah, it's a fine example of how mandating one binary format won't work. I don't even want to contemplate stuffing every program's output into the XML format... And today, every nontrivial application defines its own data formats, and they don't follow any particular conventions about how file formats should be identified. Would I propose redefining established formats like JPEG, PNG, MP3, MIDI, XCF, HTML, BLEND, and so on to fit some new scheme? Oh, hell no.
What I propose, instead, is that when a program outputs data in a particular format, it also provides some means of communicating how to interpret that data. The functional equivalent of a Python binding for the data, more or less - if it's a structure, you know what fields it provides, if it's a sequence, you can get elements out of it, if it's text, you know what encoding it's in, if it's a number, you know how to interpret it. So a process may output audio data in MP3, but at the shell level, that data would be an MP3 object. If the receiving process has specialized code for interpreting an MP3 object, it can do things like access the raw data stream (MP3 data), or use the object interface to do things at a higher level - but if it's a naive application that just knows how to deal with the shell-level concept of audio data, or audio data in some compatible format, then there'll be a conversion in there. So the shell mandates a format, but has no delusions of mandating the format.
For backwards compatibility, information like this could be provided statically - if I have a program that I know is going to put out MP3 data, that can be added as an attribute of the program in a kind of masking layer.
Yes, I certainly do want an OO shell to become so widely adopted that people won't mind coming to rely on it and integrate it into everything. My hopes can't be realized otherwise. But I know that between here and there, such a tool would first have to be useful in the current landscape before adoption could occur.
As for your other arguments -
- There's not a lot of advantages to having FTP clients as part of the kernel. I think I get what you're saying here,
Whether the result is good or not is a matter of opinion. As a Unix user I find some of their decisions distasteful, but I can understand their reasons for making the decisions they did. (The verbose command names, for instance, probably help internationalization) - but I think the direction they've gone is a smart one. They've taken the Unix philosophy of small tools that work well in combination, and extended it so it can work sensibly with much larger, more complex datatypes. Managing that level of complexity benefits from using a consistent mechanism to represent non-trivial data structures. You could create a "consistent mechanism" any way you like, of course - define IFF tags for all file types on your system, encode everything in XML - whatever - and you could still pass the data over regular interprocess pipes. However, there are some implications to this. First off, when the data format becomes significantly complex, the "human readable" advantages of text formats vanish. Fields become populated with escape characters to avoid the use of delimiter characters, the mass of data becomes too large to sensibly view with a raw dump, (or, if you're passing binary over the channel, it ceases to be "human readable" through a console dump at all), etc. Second, you're passing much more data than you need to, which can get rather wasteful. A shell that knows how to pass structured data can make intelligent decisions about how to pass that data. I think in Powershell the basic idea is that the shell helps to determine the object's lifetime, but the actual hosting of the object is done through an object manager (think CORBA).
I don't think Powershell provides any means to actually stream data. So the equivalent of "primes | head | tail" wouldn't work quite the same. (Actually, 'primes' would have to be written so as to return an object capable of generating primes, rather than as an endless data stream of primes. The shell expects 'primes' to actually finish running before calling 'head') I think it might be better to have a system where structured data can be streamed, so that programs in the pipeline don't have to wait for all the data, just the pieces they want.
Suppose I want to iterate through audio files on the filesystem - get "title" metadata from those that have it, and the length of the audio in time units, format that into a list structure and save it in an environment variable.
If this is all stuff that's part of the file format, this is not a shell programming activity at all. file(1) should be taught about all the fields in /etc/magic and then you can just capture its output and do what you wish with the various fields.
I disagree. file(1) has a very specific task - which is to make a best-guess about a file format based on its contents. If you start expecting it to be actually able to interpret all those file formats - you've got a very large program, now, implementing a lot of functionality that is the proper domain of more specialized tools. No, 'file' should simply be able to tell us what program or library on the system we should talk to if we want to interpret the file. That's where the problem crops up in my example - we have the tools - we can certainly pull out title tags with mp3info - and I expect there are other tools that could do it for other formats. The problem, at a basic level, is that these tools don't even have a common interface. It could be sufficient to say "call mp3info for this file, call sox for this file", etc - but you'd also need to supply the proper calling format and the means to parse the output to get the info you want.
This, I contend, is where an object-oriented interface is useful. You say "I want the title field from this audio file", and the shell
1: Determines the format of the file. I'd like to have that information stored in a file's extended attributes - but files lacking that (files served over NFS or off a CD-ROM, or files on systems where people just don't want a bunch of Xattr's floating around for whatever reason) could provide the information in the file extension (UGH) or using file(1) magic.
2: Find the code that tells the shell how to deal with the file. For an OO shell this would likely be a file format handling library - an interface to pre-existing utility libraries, written to work nicely with the OO shell. This library would need to provide various common interfaces to the files in question (for instance, provide a method to decode compressed audio, or tell the shell that a WAVE file is also a type of RIFF file) and provide more specific interfaces to things like format-specific (or even file-specific) data fields.
3: Call the library, making the specified requests.
The specific advantage this provides over traditional shells is that the OO shell can provide domain-specific help in obtaining the correct result. It would be possible, for instance, to have one command-line program to deal with each distinct audio format, and give them very similar interfaces, but then the script writer must take care to call the correct one for each file. It would be possible to create a master audio tool like "sox", but also give it plugin support and add plugins for all relevant file formats - but this just solves one particular case. Do we do the same for all image formats? All video formats? I think that kind of framework would be a good addition to the shell.
the OO solution would be to ask each file for this information.
I'm neither a fan of OO nor a fan of executable data that may have come off-host, but to each his own. In the case of file types, I am a fan of teaching file(1) about the format and letting it do all the messy work. Do one thing and do it well is ancient Unix wisdom more ignored than followed now-a-days, but this kind of stuff is what that program was designed to do. I do believe it is an utter mistake to judge file types by extensions.
You misunderstand, I think. Your MP3 files are not executable. However, the shell does provide an executable interface to them through format-specific libraries. So you really jus
Using objects is a very bad idea because the object itself is application specific. I don't know why everyone is acting like this Powershell interacting with objects is so new. I am dealing with the WebLogic Scripting Tool (WLST) these days which is a Jython interface to a bunch of Java APIs. I'm interacting with objects from a scripting language, and it totally sucks because my scripts don't work from one version to the next. This problem can still occur with UNIX: if you can the format of your text, your scripts are going to break. However, the very act of having to convert data to text makes you *think* about how that should be represented. It's a barrier between the internals of your application and the external world. If you expose your internal objects directly to scripts, then any internal changes you make are going to break scripts. Believe me, those internals change a heck of a lot more often than you would like them to. If you don't allow them to, then you unnecessarily burden your code with backward-compatibility problems, which is exactly what got MS' code into such a horrible state.
The new bit is that this isn't just a new scripting language or programming language, it's designed for interactive sessions, too. It's a tool that could be used equivalently to a Unix command shell - a general-purpose CLI. By contrast, scripting languages usually have their own "program state" of variables and whatnot, while files and outside programs are considered foreign territory in the language's syntax. A general-purpose CLI on the other hand, is a language in which the filesystem and outside executables is part of the program state. Executables on the path serve rougly the same purpose in Bash as Python modules do on the Python module path (though you don't have to 'import' them, of course) - it's your set of tools for that language.
/etc/passwd still has a password field even though no one uses it these days.) You could use a higher-level metaformat like XML and still you'd need to stabilize the format and tagging of the important fields, or you will hit the same compatibility that you cite - which are the result of sloppy API stabilization in object interfaces.
As for changing internals: the same can happen with text-based tools, too. In fact, it has already. I can't tell you how frustrating I find it to deal with the disparities between Solaris tools and the equivalent GNU ones - I prefer the GNU tools because I'm more accustomed to them and I think the changes they provide help to deal with a wider range of problems - but the change from one version of 'find' to another, for instance, requires the use of a different set of command line switches and different text-processing logic as a result. Things change, no matter what underlying technology you use. Stabilizing one's interfaces is a problem that must be solved regardless of whether you're streaming text or passing objects. You could standardize your field-delimiter syntax and still you'd need to stabilize your field order. (Hence,
And while specific object classes may be application-specific, the means to see what they provide is not. As with Python, you can tell what all the methods and attributes of an object are.
As for the separate output step: As I said, I'd prefer a more elegant solution. But here's the thing: along each step of a command chain, you want that data to be easy to process. It's just at the last step that you want it to be easy to read. By using structured data, the intermediate steps are some level of compromise (because - guess w
I take it you haven't installed it and tried using it yet? Um... I'll get back to you on that.
I know someone mentioned the thing is bloody slow - any other reactions to the thing?
Right now, mostly I appreciate the idea of this thing - what it's capable of and what it's striving to accomplish. I think it's a good idea. Would it be my shell of choice? Yeeg, I don't know about that, the commands are all really long and every example command from the docs is full of scary Windows-isms... I just think "complacent faith in Bourne Shell tradition" isn't the right reaction to this thing. I think it has a lot more potential than that.
Let me give an example: one that I contend could be made easier to handle by using a "modernized" and object-oriented command shell.
Suppose I want to iterate through audio files on the filesystem - get "title" metadata from those that have it, and the length of the audio in time units, format that into a list structure and save it in an environment variable. Now, with bash, I'd either need one command capable of doing this task with each of the various audio datatypes on my hard disk, or else I'd need to switch between the various file types and run the appropriate command.
Now, object-oriented shells won't magically solve all our problems - for instance, if an object for some reason decides to call its "title" field something else - or if a format doesn't have those fields (C64 SID files might have a runtime field - but that was added as an extension, so maybe not) - but the OO solution would be to ask each file for this information.
> $data = for f in (find
Presumably that would return some nil objects in one or both columns depending on what files are processed. But that's the general idea. And then I'd also like to be able to do this:
>
Seems like a nice idea to me. The Z-shell has had dynamic loading of extensions for about 10 years now. I suppose someone could have added GUI extensions that way. Maybe they have, I haven't checked on their development in a long time. Basic textual zsh works perfectly for me. Interesting. Perhaps you could enlighten me a bit as to what these zsh extensions can do? As I said I have this project that's been mulling around in my head for a few years now, for a Linux shell with similar capabilities to Powershell - and in order to justify that work and to direct in sensibly I want to have a better understanding of other shells and operating environments, what they have to offer and what went wrong. I believe in the ideas I'm advocating here, but I also know I can't take them for granted - if I fail to adequately understand Unix then I, too, am likely to reinvent it badly.
I would say I am skeptical of what a zsh extension can accomplish. Sure, a shell extension can add new functions to a shell, but how does that help with the problem of improving command pipelines? How does that help me not to forget to account for the possibility that "find" could return filenames with whitespace in them, or that a field in a character-delimited file could contain the delimiter? Or if it doesn't do that, what does it do? Glad to see though that Microsoft Windows is finally catching up to old technology in this area. Whether they've "caught up" or "caught us snoozing and lapped us" is a matter of preference, I suppose. I think it also depends on how nice the shell is to actually use. I find the high degree of verbosity in the command naming rather annoying, actually - I suppose that probably helps with L10N but I am used to CLIs being rather more compact. But in terms of functionality they've provided something that I have a strong desire to see realized on Linux.
If you look at Powershell, they've got the "read immediately" process down - commands like "Format-Table" come to mind. Yeah, big deal, right? It's what PERL was born to do. But nevertheless - if you run a command and it generates an object, a meaningful printed representation of that data appears on the console. If you want it to look nicer, there are commands to format the output. I think the shell would be better if the user didn't need to handle that step explicitly - I have some ideas for how that could be done. (I am very interested in writing a Linux shell with these kinds of capabilities.) This makes it trivially easy for programmers to modify the output, or for the users to use it in unexpected ways. It means we don't need a separate program to convert binary data to a human-readable form first. From my perspective you've got it backwards. Every single program in a pipeline chain is burdened with the job of converting "human-readable" data to a useful, processable form - and then back to text again for the next chump in the line. So maybe you save one step, because you don't need to reformat the output of your last command - but you've added on two steps for every command in the chain (minus one, for the first) - and when programs start to get even moderately outside the realm of the common, everyday stuff, the user starts having to deal with those processes themselves. Complex datatypes in a shell are only good if you're using a set of languages that can deal with the same objects. With Unix, not all your languages have a concept such as an object -- not even a struct. Even then, you need a human-readable form for them, even if they're converted at the user's request.
As long as Monad has that, it's probably decent. But that's going to be application-specific. True, that is a problem. Not so much the languages' limitations in handling objects - that's just syntax. You can write object-oriented code in C if you feel like it, and certainly C can interface with object managers like CORBA - it just wouldn't be especially fun. It's more the problem of having a common communication format - that's a hard sell because people don't think they need it, and it's a bit of a tall order to mandate something like that.
In what sense is Monad's pipeline communication format "application-specific"? It can deal with any
Want to help me write it? I have ideas and enthusiasm at this point - not much else. Talk to me if you're seriously interested in making it happen.
What's to understand here? Yeah, but how many of them are actually shells? Good shells? What's involved in running Pine from within a Python interactive session?
And then, here's my favorite bit - suppose you have code in Python that does some processing for you and generates some data - maybe even a live object - you want to pipe it out to a Ruby script. If you have an object-oriented shell you can do that shit, no problem. If you have a text-oriented shell, it depends a lot on how complex the data is.
it treats piped arguments as objects instead of strings, Psh lets programs access the data directly, instead of having to manipulate large amounts of textual data with tools such as grep or PERL.
Then they have absolutely no idea about what they are doing. The one big advantage in using pipes is that any application can handle text data.
Let me give one example: I use the sort command all the time, it sorts data by lines of text, lines are compared according to criteria passed in command options.
Now, imagine if it depended on binary objects. For every sort operation one would have to write a comparison function to decide which object should come before the other. Writing a special function would mean declaring some form of callback, or maybe some people would call it a closure, whatever. And so on.
Here's one simple command I use when a disk starts getting full to see which directory is the data hog:
du -x / | sort -nr > mem.txt &
What this command does is check the disk usage (du command) in the root directory (/) without looking at symbolic links to other disks (-x option). The result is piped to the sort function, where it's sorted by the numeric value of the first column in reverse order (-nr option). The sorted result is sent to a file named mem.txt. Since checking the whole disk may take some time, it's done in the background (& command). After it finishes, I have a file with the size of each directory in the disk, one line per directory, ordered by size, larger directories first.
See how powerful it is, having data represented as text? Try writing this line as a Powershell script.
Another advantage of having data in text format is that you can test it using the keyboard and screen very easily, no need to run a special debugger.
Instead of trying to reinvent Unix poorly, Microsoft would do a favor to its customers if they accepted Unix is a mighty fine OS and adopted without shame its best features.
I strongly disagree with most of what you've said. Here's why.
.NET provides this, of course. Similar technologies could provide the same thing on Linux. It's a tall order, mainly because of all the programs in the world that are written for naive assumptions about the shell environment...)
The supposed "ease" of dealing with text is an illusion - it's a fallacy that's built out of
1: the fact that textual formats are usually organized such that we humans can read them if we send the data out to a console
2: the fact that Unix types have built up a formidable array of text-wrangling utilities to deal with these problems
3: a general assumption that the reading and writing of formats passed between processes won't pose any real challenge to process.
The relative "ease" of text is negated if three corresponding conditions are met in a shell dealing in structured data:
1: Data is structured (or information about the structure of the data is communicated) using mechanisms that are respected by all tools involved. (In other words, there's some kind of Lengua Franca for the structured data -
2: The structured data that is used in inter-process pipelines is given suitable (preferably interactive) display methods
3: An appropriate set of data handling tools are introduced, generic enough to work for most problems and powerful enough to be effective.
The problem with textual formats for structured data is that there will always appear ways that you can do it wrong. For instance, what if a field contains the character (or set of characters) you're expecting to use to delimit the fields? Well, that's why find has a -print0 option, isn't it? Now, what if the field could contain null bytes, too? Then maybe you use escape characters - and the process of reading in the output from the previous command starts to become a more complicated parsing problem.
You cite how easy it is to sort based on a field (and, to extend the exam
-- Forgot who said it. True - but if you look at the shell they've cooked up, maybe they didn't do so poorly after all. There's a lot of great ideas in that thing.
I really, really want the Linux CLI to be modernized. (Lots of time is spent working on the Linux GUI, but it seems like when it comes to the CLI people are content to let it rot.) I've spent a lot of time trying to figure out how I would go about doing that. I've read a bit about PowerShell - it seems interesting, at least, and promising. For instance:
- It can wrangle live
- It encourages a unified interface (conventions for command options, etc.) for CLI programs and utilities
- It applies these new techniques in conjunction with existing, traditional shell mechanisms, like pipes.
- It endeavors to make documentation and general information about commands easier to access
Now, there's also things I don't like so much - for instance, the distinction between "commandlets" and normal commands. (To be fair, this is largely due to the fact that most existing code in the world is written either for a traditional CLI or a GUI - so most code isn't going to know how to deal with a smart CLI anyway. But I think there are better solutions.)
I think it's kind of a drag that Microsoft may now have a better CLI than Linux - but I think that's a situation that can be changed.
The moon is only a quarter million miles away - so you might be off by a couple orders of magnitude there.
'Cause it's HAL9000, not 9001, dur hey...
"...my boat..."
(Unlike some other Robin Hoods, I can speak with an English accent...)
I mean, sure, lots of people made the connection with HAL 9000, but this post actually got the quote right. "Open the pod bay doors" came after the lipreading scene.
What about Jennicam?
Have you seen "Grindhouse" yet?
That should clear things up.
"One Laptop Per Child" will change its name to reflect this change, it will know be known as "Four Laptops Per Seven Children"
Yep, but so did the Challenger.
The Challenger launched the Playstation 3??I agree in that when I was a college student I wouldn't have liked this sort of thing at all. But on the other hand - the school has internet access for a reason - and that reason isn't so people can download music or movies or games, and nor is it so that people can participate in serving arbitrary content - regardless of whether sharing that content is legitimate. Even though it's a service to other people, to use bittorrent to get, say, a Linux ISO instead of just leeching it - the campus network's purpose isn't to let students provide services to outsiders, it's to facilitate education. If a student could get their Linux ISO by downloading one copy, rather than downloading one copy and uploading two - that gives them the ability to get their data, but uses less of the school's networking resources to do it.
'Course, in practice the way this usually works is that hosts on the campus network that are consuming a disproportionately large amount of bandwidth will be scrutinized. So the first stage of singling people out could have nothing to do with identifying protocols or what it is the protocols are doing - just if you're using a lot of traffic you get noticed. So there are real limits to how stealthy you can be and still do what you want.
It's good to know that the guys behind "The Lame List" (or, "What's Weak This Week") are still at it...