Go back to the original ST where each episode stood by itself and was written by people with good ideas that weren't interested in developing a space soap opera.
Um, but Star Trek is a space opera and there essentially was a story arch in TOS, it was just canceled by the network before it had time to fully develop. That's at least part of what the movies were about.
What do you mean by "arch"?
<doorway and computer console appears out of thin air>
But aside from that, Firefly gave us a space show that was like Trek only in so much as there were spaceships -- everything else was as different from Trek as it was from other shows.
Man, it was Buffy in space.
How so? I mean, really, I've watched both series in their entirety more than once. How did Firefly have anything in common with Buffy?
Then you must find the warp 12(or something ridiculous like that) even more absurd and that happened during TNG(with the traveler).
Are you trying to make some kind of point here?
I mean that wasn't an especially good episode... And I'm not normally a Wesley-hater, but incidentally that was also the episode where we learn that Wesley isn't like the other boys, Wesley is special...
Did you watch DS9 after the war started and they started to let Ron Moore do his thing? Watching the creature-comfort Federation come to the brink of collapse was much more interesting than watching Picard show up at a planet and lecture the locals about their backward traditions.
Ah, but the real fun was when he'd lecture his own crew about respecting those backward traditions...
Even worse, since they're in difference universes, the navy ship has the ability to press it's own oil from shale it finds, create food incredibly cheaply, and has a ready supply of spare parts if anything breaks - the merchant doesnt
This laptop can survive wind gusts of 70mph? I should hope so. I should also hope it would survive wind gusts of 88mph, or 100mph. I'm reasonably certain that every computer I've ever owned, from my lowly C64 all the way up to my current quad-core beast, could survive wind gusts of 70mph.
With a powerful enough gust of wind striking, say, the open face of a laptop's LCD display, you could expect that force to have some kind of an effect on the hinge or possibly the LCD itself.
You mean move the laser? Why not create an optical device to deflect the beam? I am out of practice, but it seems this would be far easier.
Seems to me there's two issues with that:
First, there's a precision issue, and a related reliability issue. If you're adjusting the laser (and sensor) angle using a rotating mirror, for instance, a small change in the mirror position corresponds to a relatively large change in the read position. The reliability issue is the increased probability that such a device would become misaligned, due to its higher sensitivity.
Second, for the laser to have a fairly perpendicular angle of incidence to the disc surface by deflecting the beam would ordinarily require a fairly large distance between the deflecting device and the surface of the disc. If the angle isn't kept close enough to perpendicular, this can result in greater degrees of refraction and parallax in trying to read a bit.
Because Moore's law applies only to electronics (specifically, transistors) and not things with moving parts?
That's not totally unlike asking "Why does Moore's Law not apply to cars?"
Probably there was a time when cars followed a similar pattern of growth...
Moore's Law seems to work specifically because it's applied to a field that presently has a lot of untapped potential. Processes can continue to be refined, the market for the devices continues to grow, and as yet the limits on either haven't quite been hit.
Having only 2 ports isn't a big insurmountable problem, because USB hubs work. More convenient to have 4, of course.
Yeah, my first accessory purchase was one of those Nyko conformal hubs with the card reader built in. Still would be a lot nicer if they'd just included the ports, though.
It's much more convenient to simply have the needed ports built in.
Try checking the number of horns on a bicorn and you'll see that the google engine is not intelligent, artificial or otherwise. Or would you like to argue that bicorns are not real, and therefore don't count?
> A: *IN* the human body? Well, men can have a maximum of two (one in the rear, one in the mouth), while women can have at most three (rear, mouth, vaginal).
If goatse taught me anything it's that you shouldn't make the mistake of thinking more than one 'unit' per orifice wouldn't fit...
Though honestly, that doesn't bother me nearly as much as the fact that they reduced the number of USB ports from 4 to 2. The card reader was kind of an extaneous, unnecessary function, but the USB ports are used for charging controllers and attaching peripherals. Their frikkin' chipset probably supports four ports anyway, so removing the connectors is just a horribly cheap move.
The point is, though, that there are always ways in which an add-on module can be mismatched to the environment in which it's supposed to run. At the shell you could have a binary compiled for the wrong platform, or linked to the wrong standard library.
I assume that Microsoft could get this right for its own software, and put pressure on other software vendors to conform (although many failed to deal with user data properly in their WinXP releases).
It's simpler than that. If you want to write a commandlet for Powershell and have it work nicely, you do that. (If not, you don't.) People who are working in the.NET environment are halfway there already, of course... In such a case interfacing to Powershell is probably a handy way to perform unit testing and so on...
These binary modules would all follow an API defined by the shell governing how they take data in and write data out
And what of programs that don't follow this?
Such programs (I have a handy name for them: I call them "every program I've ever used":D) would simply not be able, out of the box, to take advantage of the extra functionality the shell has to offer. In Powershell this means they'd work more or less like they would in more traditional shells - piping text, and able to communicate with Powershell "commandlets" only in terms of textual repesentations of objects, as opposed to references to live objects.
The data objects being read and written would similarly follow a few basic rules - a common mechanism for memory management and method invocation, some mandatory methods (like the one used to display the object on-screen as text), and so on.
So Eric Raymond's warning about having programs know too much of each others internal workings means nothing to you? How would one get the data objects? From the shell? Or from programs written in a zillion languages? You expect some common mandatory methods, even from data objects in languages without OO?
OK, first, I'm talking about Powershell's approach here, describing it in Unix terms, and how the same approach would be implemented without.NET. I wanted to clarify what it does, and how. This isn't the approach I advocate for Unix, personally...
Second, when you're talking about something esr said - I don't know what it was, or in what context. The way you're talking about it, though, it almost sounds like you're saying I should heed that warning because he's Eric Raymond. At face value I'd say it's a question of how far the approach is taken. If you go n steps in terms of mandating common conventions between programs, that's what you'd call a coherent architecture. Go n+m steps, and you get excessive dependence on implementation details, etc.
As for "expecting common methods, even from languages that don't support OO" - sure, why not? It's not as though non-OO languages are fundamentally at odds with the idea of OO code, they just don't have nice support for it. To get a usable object interface you need a few common conventions followed. It just doesn't work otherwise.
It seems to me that you require a great deal of coordination between your shell and executables. How would you achieve this? Would the shell be able to deal with any executable? Or would programmers in other languages be expected to conform to the shell?
I have given all these problems a great deal of thought. I'll describe here how I plan to solve these sorts of problems. My approach is a bit different from Powershell's for various reasons...
First: In Powershell, the "commandlets" are dynamically linked in and run as part of the shell's process. That can work in.NET beca
Come on, Dreamweaver, you've never given up on anything in your life! There still may be some time... Everything's going to be OK. Say it with me: "I believe we can reach the morning light".
The exact format of a program's input or output may change from release to release with no coherent strategy for establishing any kind of compatibility. In comparison, in Powershell a piece of data passed from one process to another has a predictable underlying structure - it's formatted for consumption by another process rather than for display at the terminal.
I do not find the basic assumption valid (that Unix pipelines are destined for human readable output) and I also see no difference in the two cases you described above. Data representation can change too.
The difference is that if the.NET object format changes, compatibility with the previous format can be maintained... In contrast, if you're dealing with a shell utility whose ad-hoc data format changes, the maintenance required to support that change is not at all centralized - it affects any shell script that works with that data, and these may not be easy to identify.
If plain text is not used for human-readability, then what good is it, really?
You could as easily ask "what if Python's assumptions about the format of classes doesn't match the assumptions made in this compiled Python module?" It represents a failure to build the module properly for the environment in which it'll run.
Of course, in Python I might have access to the source from which it was compiled. Hoe much of the source to Powershell is available?
That's not likely to be much of an issue in Powershell. Since the whole thing runs on.NET, the shell and the commandlets share the same idea about how data is represented anyway...
The point is, though, that there are always ways in which an add-on module can be mismatched to the environment in which it's supposed to run. At the shell you could have a binary compiled for the wrong platform, or linked to the wrong standard library.
And if you want to talk about compatibility of this format between releases - that really just becomes a more centralized burden when you're dealing with a more rigorously defined data exchange format.
You say that you want programs to communicate better with each other, better in what way? It may be that Powershell can do what you want in Windows, but this may be because Windows supports such a shell. The problem in writing such a shell for Unix is that the OS itself may lack features to support it. Indeed, if Eric Raymond is correct, Unix was designed not to support such features.
Powershell is just an example of this approach. The reasons it works well in Windows are because it has extensive access to Windows APIs and because it has the.NET environment supporting it, acting as a stable binary platform for modules supporting reflection.
What Unix was designed for, years ago, doesn't concern me so much. It is capable of acting as the basis for platforms beyond its basic design. This is done all the time with GUI environments, for instance.
If you dropped the whole.NET angle and some of the other syntax features and just wrote a Unix shell that was a straightforward clone of the Powershell model, it would be something like this:
At the simplest level, it's an ordinary shell
However, it also supports another PATH-like variable on which it can find binary modules which can be run like ordinary commands.
These binary modules would all follow an API defined by the shell governing how they take data in and write data out
The data objects being read and written would similarly follow a few basic rules - a common mechanism for memory management and method invocation, some mandatory methods (like the one used to display the object on-screen as text), and so on.
The shell has support for working with the objects output by these commands - it can store them in variables, display them (by invoking the objects' display methods), it gives the user a way to find out what other methods the object supports, and allows the user to invoke those methods.
Some capability is provided to make these loadable module-commands interact nicely with ordinary programs on the PATH.
There's nothing about the basic concept that exceeds what Unix is capable of, or even (IMO) what it was "designed for". All the above design needs is "dlopen()" combined with some establishment of policies. And, of course, there are other ways you could implement the same sort of capabilities. (For instance, to run these commands as separate processes - which might be a preferable approach on Unix since it does not ordinarily provide the kinds of protections available to code running in.NET)
The context of the whole discussion has changed gradually - away from Powershell as an example of the approach I'm advocating and more toward my own ideas about how such concepts could be incorporated into the shell... There is a design I've been working on - I'm pretty much dealing with this discussion now in terms of that design and what I want to accomplish with it.
i think at this point, we just have (potentially unresolvable) philosophical differences.
I'm OK with that if you are.:) If you don't find the discussion interesting then I'm not offended if you don't want to continue.
In general, when I enter into a discussion like this I have to try very hard to argue the point well, and still I think I don't always make a good case for it. There's always more for me to learn, too, about how things work in the current shells.
you talk about linking applications against a particular library for the shell, and the shell automatically transforming data, and such without recognizing that such things are antithetical to the design, intent, and evolution of the Unix shell.
For sure it's a huge change that I'm suggesting. I feel like it's an improvement, but I understand that many people won't share my opinion.
Writing code specifically for the shell is a somewhat alien idea, admittedly. But I think it's a good thing, if it means the shell can be substantially more powerful and capable as an interactive language as a result.
But it's a bit misleading to suppose that we don't already write programs specifically for use in the shell. Don't we use libraries for parsing command-line arguments, for instance? Don't we adhere to a set of arbitrary conventions about how the program is started and run? Don't people generally attempt to make their shell tools' output at least somewhat easy to handle with sed, awk, etc.? I'm proposing changing out one set of conventions for another - to say it's an uphill battle would be a ridiculous understatement.:D
That said, in my design I do recognize that working nicely with code not written specifically for the shell is critically important. That would be "every program in the world" at present.:D I try to avoid words like "legacy" when talking about such code for this exact reason. I wouldn't say I've entirely solved the problem in my design, though...
There's different ways this compatibility can be dealt with: there's the default, minimalistic assumption about such programs (text input, text output, text stderr), and there's the option of letting the user or sysadmin statically tag the program, or wrap it in a shell script, in order to provide a translation layer (like "split text by line, split lines by colon delimiter")
Another possible method for determining the output format of a program would be to attempt to guess - but this is difficult since normally the shell doesn't monitor a pipelined process's output at all - it just creates the pipe and then execs the processes. To monitor a pipe, even just the first dozen bytes or so, would require a second pipe, and the shell process continuing to pass data from one pipe to the next for the remainder of the execution... (Well, it might be possible to read from the read end of the pipe and then push the data back into the buffer, or something - I don't really know. I'll have to reread my Unix Programming book...) That's something I'd generally like to avoid.
One of the places the design really fails at present is terminal applications - things like alpine, aptitude, pretty much anything that uses curses. These programs don't really take values in and write values out at all - rather, they're applications requiring a certain sort of display interface, the terminal. But Unix traditionally provides no clear way to distinguish these from "tools", so I don't have a way to make the shell automati
Slashdot Mirror
Do we have time to make a batch of Torgo's Executive Powder?
Torgo's busy, taking care of the place while The Master is away.
Go back to the original ST where each episode stood by itself and was written by people with good ideas that weren't interested in developing a space soap opera.
Um, but Star Trek is a space opera and there essentially was a story arch in TOS, it was just canceled by the network before it had time to fully develop. That's at least part of what the movies were about.
What do you mean by "arch"?
<doorway and computer console appears out of thin air>
Well, shit.
But aside from that, Firefly gave us a space show that was like Trek only in so much as there were spaceships -- everything else was as different from Trek as it was from other shows.
Man, it was Buffy in space.
How so? I mean, really, I've watched both series in their entirety more than once. How did Firefly have anything in common with Buffy?
"(But not Warp 10 retarded shit VOY broke out)"
Then you must find the warp 12(or something ridiculous like that) even more absurd and that happened during TNG(with the traveler).
Are you trying to make some kind of point here?
I mean that wasn't an especially good episode... And I'm not normally a Wesley-hater, but incidentally that was also the episode where we learn that Wesley isn't like the other boys, Wesley is special...
Did you watch DS9 after the war started and they started to let Ron Moore do his thing? Watching the creature-comfort Federation come to the brink of collapse was much more interesting than watching Picard show up at a planet and lecture the locals about their backward traditions.
Ah, but the real fun was when he'd lecture his own crew about respecting those backward traditions...
Also, there are four lights.
Even worse, since they're in difference universes, the navy ship has the ability to press it's own oil from shale it finds, create food incredibly cheaply, and has a ready supply of spare parts if anything breaks - the merchant doesnt
You lost me. Maybe you could try a car analogy?
This laptop can survive wind gusts of 70mph? I should hope so. I should also hope it would survive wind gusts of 88mph, or 100mph. I'm reasonably certain that every computer I've ever owned, from my lowly C64 all the way up to my current quad-core beast, could survive wind gusts of 70mph.
With a powerful enough gust of wind striking, say, the open face of a laptop's LCD display, you could expect that force to have some kind of an effect on the hinge or possibly the LCD itself.
Better yet, just keep an extra, broken drive physically mounted in the machine. Don't actually hook it up to anything... use that to show off. :D
You mean move the laser? Why not create an optical device to deflect the beam? I am out of practice, but it seems this would be far easier.
Seems to me there's two issues with that:
First, there's a precision issue, and a related reliability issue. If you're adjusting the laser (and sensor) angle using a rotating mirror, for instance, a small change in the mirror position corresponds to a relatively large change in the read position. The reliability issue is the increased probability that such a device would become misaligned, due to its higher sensitivity.
Second, for the laser to have a fairly perpendicular angle of incidence to the disc surface by deflecting the beam would ordinarily require a fairly large distance between the deflecting device and the surface of the disc. If the angle isn't kept close enough to perpendicular, this can result in greater degrees of refraction and parallax in trying to read a bit.
Because Moore's law applies only to electronics (specifically, transistors) and not things with moving parts?
That's not totally unlike asking "Why does Moore's Law not apply to cars?"
Probably there was a time when cars followed a similar pattern of growth...
Moore's Law seems to work specifically because it's applied to a field that presently has a lot of untapped potential. Processes can continue to be refined, the market for the devices continues to grow, and as yet the limits on either haven't quite been hit.
I guess people are making seriously hardcore DVDs with this thing. I mean, most of my DVDs are just three X's, which is plenty for my needs...
Having only 2 ports isn't a big insurmountable problem, because USB hubs work. More convenient to have 4, of course.
Yeah, my first accessory purchase was one of those Nyko conformal hubs with the card reader built in. Still would be a lot nicer if they'd just included the ports, though.
It's much more convenient to simply have the needed ports built in.
Try checking the number of horns on a bicorn and you'll see that the google engine is not intelligent, artificial or otherwise. Or would you like to argue that bicorns are not real, and therefore don't count?
Well, the proper term is "twonicorn".
> A: *IN* the human body? Well, men can have a maximum of two (one in the rear, one in the mouth), while women can have at most three (rear, mouth, vaginal).
If goatse taught me anything it's that you shouldn't make the mistake of thinking more than one 'unit' per orifice wouldn't fit...
Ever seen Orgazmo? Truly a fine piece of film.
D.V.D.A...
Curious. Your post prompted me to have a conversation with Eliza, copied here:
You know, this makes me wonder what progress could be made in developing a Bud Abbott simulator...
> Tell me about the bones in the human body
Well, there's lots of bones in the human body, they all have these funny names...
> Like what?
Yes.
> Yes?
No.
> What?
Yes.
> Look, I just want to know about the bones in the human body.
Like what?
> The bones, in the human body.
Such as what?
> I don't know, any bones.
No, there's not any bones in the human body.
> There are no bones in the human body?
Yes.
> Look, I'm able to stand upright and all so I'm pretty sure there are bones in my legs.
There are no bones in your legs.
> Then how am I standing? With no bones?
Yes.
> What?
What bones are in your arms.
> Wouldn't I like to know!
You mean like:
They removed it, remember?
Though honestly, that doesn't bother me nearly as much as the fact that they reduced the number of USB ports from 4 to 2. The card reader was kind of an extaneous, unnecessary function, but the USB ports are used for charging controllers and attaching peripherals. Their frikkin' chipset probably supports four ports anyway, so removing the connectors is just a horribly cheap move.
The point is, though, that there are always ways in which an add-on module can be mismatched to the environment in which it's supposed to run. At the shell you could have a binary compiled for the wrong platform, or linked to the wrong standard library.
I assume that Microsoft could get this right for its own software, and put pressure on other software vendors to conform (although many failed to deal with user data properly in their WinXP releases).
It's simpler than that. If you want to write a commandlet for Powershell and have it work nicely, you do that. (If not, you don't.) People who are working in the .NET environment are halfway there already, of course... In such a case interfacing to Powershell is probably a handy way to perform unit testing and so on...
These binary modules would all follow an API defined by the shell governing how they take data in and write data out
And what of programs that don't follow this?
Such programs (I have a handy name for them: I call them "every program I've ever used" :D) would simply not be able, out of the box, to take advantage of the extra functionality the shell has to offer. In Powershell this means they'd work more or less like they would in more traditional shells - piping text, and able to communicate with Powershell "commandlets" only in terms of textual repesentations of objects, as opposed to references to live objects.
The data objects being read and written would similarly follow a few basic rules - a common mechanism for memory management and method invocation, some mandatory methods (like the one used to display the object on-screen as text), and so on.
So Eric Raymond's warning about having programs know too much of each others internal workings means nothing to you? How would one get the data objects? From the shell? Or from programs written in a zillion languages? You expect some common mandatory methods, even from data objects in languages without OO?
OK, first, I'm talking about Powershell's approach here, describing it in Unix terms, and how the same approach would be implemented without .NET. I wanted to clarify what it does, and how. This isn't the approach I advocate for Unix, personally...
Second, when you're talking about something esr said - I don't know what it was, or in what context. The way you're talking about it, though, it almost sounds like you're saying I should heed that warning because he's Eric Raymond. At face value I'd say it's a question of how far the approach is taken. If you go n steps in terms of mandating common conventions between programs, that's what you'd call a coherent architecture. Go n+m steps, and you get excessive dependence on implementation details, etc.
As for "expecting common methods, even from languages that don't support OO" - sure, why not? It's not as though non-OO languages are fundamentally at odds with the idea of OO code, they just don't have nice support for it. To get a usable object interface you need a few common conventions followed. It just doesn't work otherwise.
It seems to me that you require a great deal of coordination between your shell and executables. How would you achieve this? Would the shell be able to deal with any executable? Or would programmers in other languages be expected to conform to the shell?
I have given all these problems a great deal of thought. I'll describe here how I plan to solve these sorts of problems. My approach is a bit different from Powershell's for various reasons...
First: In Powershell, the "commandlets" are dynamically linked in and run as part of the shell's process. That can work in .NET beca
Dreamweaver Is Dying
As Richter said in Total Recall: "About damn time."
Andy Richter was in Total Recall?
Man, I gotta watch that movie again...
Come on, Dreamweaver, you've never given up on anything in your life! There still may be some time... Everything's going to be OK. Say it with me: "I believe we can reach the morning light".
Shell To Frustrate Users?
If you read my other posts on this discussion... The answer, quite possibly, is yes. :D
I don't know who this "The Flash" is...
http://lmgtfy.com/?q=%22The+Flash%22
"But this reminds me of some odd invoices I've seen here lately at Star Labs."
Crap. Let me try that again.
"But this reminds me of some odd invoices I've seen here lately at Star Labs."
The exact format of a program's input or output may change from release to release with no coherent strategy for establishing any kind of compatibility. In comparison, in Powershell a piece of data passed from one process to another has a predictable underlying structure - it's formatted for consumption by another process rather than for display at the terminal.
I do not find the basic assumption valid (that Unix pipelines are destined for human readable output) and I also see no difference in the two cases you described above. Data representation can change too.
The difference is that if the .NET object format changes, compatibility with the previous format can be maintained... In contrast, if you're dealing with a shell utility whose ad-hoc data format changes, the maintenance required to support that change is not at all centralized - it affects any shell script that works with that data, and these may not be easy to identify.
If plain text is not used for human-readability, then what good is it, really?
You could as easily ask "what if Python's assumptions about the format of classes doesn't match the assumptions made in this compiled Python module?" It represents a failure to build the module properly for the environment in which it'll run.
Of course, in Python I might have access to the source from which it was compiled. Hoe much of the source to Powershell is available?
That's not likely to be much of an issue in Powershell. Since the whole thing runs on .NET, the shell and the commandlets share the same idea about how data is represented anyway...
The point is, though, that there are always ways in which an add-on module can be mismatched to the environment in which it's supposed to run. At the shell you could have a binary compiled for the wrong platform, or linked to the wrong standard library.
And if you want to talk about compatibility of this format between releases - that really just becomes a more centralized burden when you're dealing with a more rigorously defined data exchange format.
You say that you want programs to communicate better with each other, better in what way? It may be that Powershell can do what you want in Windows, but this may be because Windows supports such a shell. The problem in writing such a shell for Unix is that the OS itself may lack features to support it. Indeed, if Eric Raymond is correct, Unix was designed not to support such features.
Powershell is just an example of this approach. The reasons it works well in Windows are because it has extensive access to Windows APIs and because it has the .NET environment supporting it, acting as a stable binary platform for modules supporting reflection.
What Unix was designed for, years ago, doesn't concern me so much. It is capable of acting as the basis for platforms beyond its basic design. This is done all the time with GUI environments, for instance.
If you dropped the whole .NET angle and some of the other syntax features and just wrote a Unix shell that was a straightforward clone of the Powershell model, it would be something like this:
There's nothing about the basic concept that exceeds what Unix is capable of, or even (IMO) what it was "designed for". All the above design needs is "dlopen()" combined with some establishment of policies. And, of course, there are other ways you could implement the same sort of capabilities. (For instance, to run these commands as separate processes - which might be a preferable approach on Unix since it does not ordinarily provide the kinds of protections available to code running in .NET)
The context of the whole discussion has changed gradually - away from Powershell as an example of the approach I'm advocating and more toward my own ideas about how such concepts could be incorporated into the shell... There is a design I've been working on - I'm pretty much dealing with this discussion now in terms of that design and what I want to accomplish with it.
i think at this point, we just have (potentially unresolvable) philosophical differences.
I'm OK with that if you are. :) If you don't find the discussion interesting then I'm not offended if you don't want to continue.
In general, when I enter into a discussion like this I have to try very hard to argue the point well, and still I think I don't always make a good case for it. There's always more for me to learn, too, about how things work in the current shells.
you talk about linking applications against a particular library for the shell, and the shell automatically transforming data, and such without recognizing that such things are antithetical to the design, intent, and evolution of the Unix shell.
For sure it's a huge change that I'm suggesting. I feel like it's an improvement, but I understand that many people won't share my opinion.
Writing code specifically for the shell is a somewhat alien idea, admittedly. But I think it's a good thing, if it means the shell can be substantially more powerful and capable as an interactive language as a result.
But it's a bit misleading to suppose that we don't already write programs specifically for use in the shell. Don't we use libraries for parsing command-line arguments, for instance? Don't we adhere to a set of arbitrary conventions about how the program is started and run? Don't people generally attempt to make their shell tools' output at least somewhat easy to handle with sed, awk, etc.? I'm proposing changing out one set of conventions for another - to say it's an uphill battle would be a ridiculous understatement. :D
That said, in my design I do recognize that working nicely with code not written specifically for the shell is critically important. That would be "every program in the world" at present. :D I try to avoid words like "legacy" when talking about such code for this exact reason. I wouldn't say I've entirely solved the problem in my design, though...
There's different ways this compatibility can be dealt with: there's the default, minimalistic assumption about such programs (text input, text output, text stderr), and there's the option of letting the user or sysadmin statically tag the program, or wrap it in a shell script, in order to provide a translation layer (like "split text by line, split lines by colon delimiter")
Another possible method for determining the output format of a program would be to attempt to guess - but this is difficult since normally the shell doesn't monitor a pipelined process's output at all - it just creates the pipe and then execs the processes. To monitor a pipe, even just the first dozen bytes or so, would require a second pipe, and the shell process continuing to pass data from one pipe to the next for the remainder of the execution... (Well, it might be possible to read from the read end of the pipe and then push the data back into the buffer, or something - I don't really know. I'll have to reread my Unix Programming book...) That's something I'd generally like to avoid.
One of the places the design really fails at present is terminal applications - things like alpine, aptitude, pretty much anything that uses curses. These programs don't really take values in and write values out at all - rather, they're applications requiring a certain sort of display interface, the terminal. But Unix traditionally provides no clear way to distinguish these from "tools", so I don't have a way to make the shell automati
I don't know who this "The Flash" is...
http://lmgtfy.com/?q=%22The+Flash%22
"But this reminds me of some odd invoices I've seen here lately at Star Labs."