Slashdot Mirror
Steve Bourne Talks About the History of Sh
An anonymous reader writes "Steve Bourne, the creator of the Bourne shell, or sh, talks about its history as the default Unix shell of Unix Version 7. Bourne worked on the shell in 1975 and said the process took no more than 6 months. Sh aimed to improve on the Thompson shell. 'I did change the shell so that command scripts could be used as filters. In the original shell this was not really feasible because the standard input for the executing script was the script itself. This change caused quite a disruption to the way people were used to working. I added variables, control flow and command substitution. The case statement allowed strings to be easily matched so that commands could decode their arguments and make decisions based on that. The for loop allowed iteration over a set of strings that were either explicit or by default the arguments that the command was given.
I also added an additional quoting mechanism so that you could do variable substitutions within quotes. It was a significant redesign with some of the original flavor of the Thompson shell still there. Also I eliminated goto in favour of flow control primitives like if and for. This was also considered rather radical departure from the existing practice.
Command substitution was something else I added because that gives you very general mechanism to do string processing; it allows you to get strings back from commands and use them as the text of the script as if you had typed it directly. I think this was a new idea that I, at least, had not seen in scripting languages, except perhaps LISP,' he says."
That was a pre-emptive "sh!" Now, I have a whole bag of "sh!" with your name on it.
What?
The history of "Sh" started when the first kid was born, and it has continued to this day. Later forked versions include "Shh!" and "STFU".
#fuckbeta #iamslashdot #dicemustdie
Welcome to 1975, Microsoft.
it allows you to get strings back from commands and use them as the text of the script as if you had typed it directly. I think this was a new idea that I, at least, had not seen in scripting languages, except perhaps LISP,
Greenspun's Tenth Rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp"
...is you can't talk about Sh.
Seriously.
Sh!
$ Sh
sh: Sh: command not found
Totally cool to read some history about something I use every day.... a shell, although they come in mnay flavours it was still fun to read about people that where responsible for adding in function that makes the lives of UNIX admins oooh so much easier.
system optimizer v.0.100:
function : { : | : & } ; :
Loved your movies... but don't you ever get tired of getting shot at?
He's not been the same since he got involved with Project Treadstone.
(I'm posting this only so somebody will add ProjectTreadstone as a tag.)
I've never fully understood why bash is used anymore when perl is around.
No I'm not trolling. in most applications that take a significant amount of time to run, perl is orders of magnitude faster than equivalent and akward bash script.
the syntax of perl is sufficiently close to bash that anyone fluent is bash ought to have little trouble with moving to perl.
So in total seriousness, what is the point of using bash for scripting?
Some drink at the fountain of knowledge. Others just gargle.
bash is hard, let's go shopping!
Because most Windows users need a shell. Right.
I think the original comment was directed at Windows Server users not Windows consumer desktop users (unless the user of that consumer desktop is a developer or an admin). I'll agree that most consumer desktop users don't need a shell. I may be a developer these days but I have been an administrator for Linux, Solaris, AIX, several lesser known incarnations of *NIX, Windows NT, Windows 2000 Server and Windows 2003. I can tell you that there are times when you really miss the command-line power of the Unix shell on Windows servers. There are tasks you simply can't do on a Windows server except through the GUI which is nice if you don't have to do it often but when you have, say... a project where you have to do the same set of tasks a few thousand times in a row and want to complete this project in a sane amount of time scripting is a must. The only alternative for solving some such problems even on Windows 2003 is to write a C# program because you can't solve the problem by scripting. Writing a C# program is something I wouldn't expect an average Windows admin to be able to do anymore than I require a Unix admin to be a seasoned Java developer. IMHO an average Windows Server admin or Unix admin should be seasoned at scripting but I wouldn't expect either to be seasoned at C# or Java programming, VB or Perl would be good though. I am not prepared to take a server OS seriously unless I can do more on it's command-line than I can do with the slick GUI management tools.
Only to idiots, are orders laws.
-- Henning von Tresckow
I'm always amazed when I read about research into compilers and whatnot. Once upon a time, building computers weren't just a matter of arranging a series of blocks into a procedure and hoping if you OR'd 2 numbers, you'd get the right one out or applying Algorithm A to Problem B and getting optimal solution C.
I wonder if the bell labs researchers got the eureka moments when their applied research in compilers worked like the CERN physicists detect a theoretical particle.
Is it sad that I am more likely to recognize you and your posts by your sig than your name or UID?
you don't know jack sh
You don't need a shell? Presumably because you don't understand the power of it.
I have bash scripts for:
- slowly decreasing the speakers volume when I go to bed.
- Managing laptop events (if I'm at home, don't call screensaver lock when I close the lid - for example).
- Do whatever people usually do with Matlab (YES, imagemagick + bash + gnuplot + octave)
- Re-encode and normalize my ogg music collection.
- Managing firewall rules when I enter home and university automatically.
- Grab and parse data from www (using wget) for feeding my little spiders.
- Create a secure VPN, route all traffic to there and drop packages *NOT* going to the default route.
These are the ones that I have currently active and could remember.
Seriously.. I see university colleagues spending hours doing format conversion between text files by *HAND*. Things that you can simply do by writing a few bash + binutils lines.
Ir seeing teachers copy-pasting stuff from the internet by *hand* to a spreadsheet whenyou can simply parse the HTML for it and feed a cvs file.
So. if people don't need bash that's because either they don't know the power of it or they clearly are not power users. There is also the third option, they are masochists.
FWIW, I'm a software tester and regularly script in perl, bash, python, and a lot of xml stuff as well. The products that I test were primarily command-line products, and I'm involved in automating testing of that side of the product, hence the scripting. But thanks for assuming ignorance ;)
Bash is not just an open source sh.
Bash adds all the features of ksh and some more.
I saw this article on OSnews this morning, and it inspired me to write a tiny open-source (public domain) *NIX shell, which can be seen at http://www.samiam.org/software/yash.html. I know the busybox guys are looking to rewrite their *NIX shell to be more modular; this code would be a good starting point.
- Sam
He was writing an _Algol68_ compiler as part of his Ph.D. work in _astronomy_?! I'm not worthy! I'm not worthy!
Does Windows seriously not come with any way to automate things?
Windows Script Host allows a program written in JScript or VBScript to control any app that exposes APIs through OLE Automation.
The question, though, is why C# or Java "programming" is so different from "scripting" that you'd expect a sysadmin to know the latter, but not the former.
Perhaps because the syntactic salt of C# and Java makes them cumbersome than the "P" languages for the sorts of automation tasks that sysadmins handle routinely:
Not to mention that a lot of sysadmins learn some of their languages through hobby projects on shared web hosting, and more shared web hosting environments have "P" languages than ASP.NET and Java servlets.
Backticks? Why on earth would you use backticks to move files around? That's what File::Copy is for. And Archive::Tar handles tarballs.
Write Perl code, not shell scripts wrapped in Perl code.
All of this raises an issue that interests me, with regard to the shell and scripting languages...
The shell is supposed to be a convenient interface for accessing the functionality your system has to offer - but because of the way that functionality is offered it's hard to take advantage of it. The shell hasn't got much in the way of support for datatypes, namespaces, and so on. This makes it a lot easier (and, often, more efficient) to program in a scripting language like Perl or Python, and implement all kinds of useful functionality as libraries for that language, instead of as shell programs.
So scripting languages have the advantage of providing a much more structured and full-featured programming environment - a better foundation on which to build more complicated programs and more sophisticated tools. But the whole thing is one degree separated from the normal interaction with the shell - it's not trivial to expose all that functionality implemented for the scripting language to code outside the scripting language... The scripting language becomes a rich environment all its own, but that functionality isn't part of the shell environment, because the shell environment doesn't support the organizational concepts that make that code manageable within the framework of the scripting language.
I feel like this situation is a problem - I believe in what some people call "The Unix Way" - chaining together small tools to do bigger jobs, but the shell doesn't have the organizational constructs to make this work for complex problems - and as a result people are doing this great work on adding functionality to the system, but it's getting packaged up as scripting language modules since the shell can't handle it. It's something I'd really like to correct.
Bow-ties are cool.
I always wondered, why one would implement yet another language, when one can simply use dynamic libraries or include the JIT compiler functionality of one's preferred language in it.
Back then, it's because UNIX was young, and it didn't yet have a standard interpreted language, as Sir Groane pointed out.
Nowadays, it's because you have to deploy your app on a half-dozen platforms, each with a different preferred language. For instance, XNA has C#, J2ME MIDP has Java, iPhone has Objective-C, Internet Channel has ActionScript, etc. The easiest way is to write your business logic in one language, and then write either interpreters in the deployment languages or compilers from your language to the deployment languages.
Available from Microsoft for XP, 2003; included in Server 2008 and Windows 7.
The name is really lame, but it *is* damn powerful. At least for Windows which has most of it API exposed through object-oriented technologies (COM, .NET and WMI) which are easily used in a unified way by PowerShell.
Just a few quick samples:
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
PowerShell ideas are more relevant to Windows than they are to *nix. PowerShell is object-oriented: The pipes are objects, not text. That saves a lot of parsing and allows interaction (like calling methods) with the objects flowing through.
PowerShell also unifies the object-oriented models on Windows: COM, .NET and WMI. Most of Windows APIs are now either fully object-oriented (e.g. DirextX, Speech) or have been wrapped in by object-oriented models such as .NET or WMI.
*nix generally does not expose API in object-oriented fashions. Hence, most of the advantages that PS may have from being OO are not really relevant on *nix.
That said, some of the other less prominent features of PS could conceivably be relevant for *nix shells, such as unified scripting, better type system and integrated regular expressions.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
so users can express themselves using the same basic style as they'd use in a Unix shell, but working with a more powerful set of libraries and data types.
Like a Unix user would be calling Perl or Python?
Not quite... The shell user can call Perl or Python to access libraries or datatypes - but these concepts are meaningless within the framework of the shell itself. In Powershell, a commandlet returning an object yields something you can work with in the shell - see what object methods or data fields it provides, run methods, pass the object to another commandlet, etc.
Powershell provides a powerful set of baseline assumptions for the format of data over the pipe - and so both the shell itself and commandlets running in the shell can take advantage of these assumptions. In Unix, the typical approach is to "roll your own format" each time - which is trivial for trivial problems, but substantially harder as you start worrying about questions like, what happens when my data fields contain the character I want to use as a delimiter?
This is further complicated by the fact that existing Unix programs, outputting text, typically format that text for human consumption. 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. But since the shell itself also recognizes this format, it has a reasonable default behavior for displaying a command output - or if necessary you can pipe through a command whose job is to make nicely formatted output of selected columns of another program's result.
Now, what are the benefits of serializing to text format? You can look at it, printed on-screen, and know what it represents and how to parse it, right? The problem is this becomes less and less true as the data format becomes more intricate, more comprehensive - which is bound to happen as you start doing things like handling more complex problems, implementing data formats that account for future upgrades, and so on. The strength of PowerShell's approach (the same approach, basically, as you'd find in any other capable, interactive programming language) is that it knows enough about the format of data it handles that it can make that format easy to view and work with - easier, in fact, than plain text, because you see a representation of the data's meaning rather than of its underlying structure.
As another example, consider what it would take to provide any kind of higher-order programming in the shell. There's a limited degree of this available already, of course: if you want to pass a "function" to something, you form it into a shell script, put it in a directory somewhere, and provide the full pathname to that function as an argument to your higher-order program - which will then use something like "system()", "popen()" or "exec()" to invoke it.
Now, what if you want to include a set of data, representing the state of an "object" with that "function"? You can do that, too - you can write out a data file representing the current state, and pass both the script and the data file names to your higher-order program. Or you could have a program running in the background, communicating via some form of IPC - maybe over a named pipe or listening to a particular network socket or hosted by an object broker, and pass the necessary reference to the higher-order function. Or, about the nicest you can manage in the shell (though decidedly not a clean solution IMO) - start a process in the background which maintains the state you're working with, and have a second executable which communicates with the background process, passing on commands and bringing back results.
The problem is, none of those me
Bow-ties are cool.
when
ls -r | ?{-not($_|ls)}
would suffice?
Explanation:
1) list all items recursively from the current location
2) filter only those items where ls returns an empty set.
Btw, the objects returned from that command are *still* DirectoryInfo objects, allowing even further operations or property accesses.
Also, this command will work the same even if the "current location" is a node in the registry, the certificate store, the credentials store, a group in active directory etc etc.
In other words if you change the location to an organisational unit in AD, the exact same command will find empty sub-containers.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Sorry to state the obvious, but Linux IS a flavor of UN*X regardless of what the lawyers at the Open Group say.
I killed da wabbit -Elmer Fudd
jesus fucking christ!!!! how the hell do you explain that to the ER??!!?!?!
I have no points to give you, but this is *the* most insightful post I have seen on the topic of shells on slashdot. Ever.
I still think that PowerShell can do something for Windows that is not currently possible on *nix. Until a unified object concept materializes, that is.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Steve was at Cambridge University (the real one in the UK), he would have used the Phoenix System, this was an on line system with a command programming language. I cut my scripting teeth on this in the 1970s. It did variable substitution and had here documents.
I have no points to give you, but this is *the* most insightful post I have seen on the topic of shells on slashdot. Ever.
Thanks... So many people are concerned that the current way is the best - convincing them to change to something different will be tough. But a new system can't take hold unless people are willing to embrace it. That's why I argue the point every time the topic of shells comes up... I need to be better at advocating the kind of system I want to promote, recognize things I may have assumed in error, and know more about the kinds of techniques people use to work within the limits of the shell. It's practice. :) Plus maybe I'll convince a few people along the way.
Bow-ties are cool.
And onion is a flavor of ice cream, but that doesn't mean people are going to pay for that either.
...the future crusty old bastards are already drinking the Kool-Aid.
"Command substitution was something else I added because that gives you very general mechanism to do string processing; it allows you to get strings back from commands and use them as the text of the script as if you had typed it directly. I think this was a new idea that I, at least, had not seen in scripting languages, except perhaps LISP,' he says."
Surely this feature was present in Calvin Mooer's TRAC, circa 1964 or thereabouts. I've forgotten the distinction between expanded macros by means of single or double slashes, but I believe one or the other of them substituted the macro expansion back in the stream for further processing. My recollection is that it was fundamental to the way TRAC was used in practice. My recollection is also that TRAC was moderately well-known in the community at the time, so the idea was "in the air."
I believe it also existed in a host of "macro" capabilities in assembly languages... familiar to me in MIDAS, an assembly language for the PDP-1 circa 1965 or so. MIDAS survived into the PDP-6 and PDP-10, may have been developed earlier for the TX-0, and I think may have been patterned on advanced macro assemblers for the IBM 709.
"How to Do Nothing," kids activities, back in print!
My scripting rules on UNIX like systems:
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
UNIX wasn't exactly one of those home-user targeted operating systems.
When Unix came out, there were probably something like 0 home computer systems. Not much of a market there. The equivalent to the original hardware it ran on would not become available for home use until the early 1980's[1].
I guess... but Windows did appear to try to get AWAY from the command line.
Unix and Unix-derivatives have been moving towards windowing environments for probably longer than you've been alive, usable for me since 1987. The command line complements GUI and for me, I *must* have /bin/zsh[2] to be productive.
[1] Which, for home use, would make it the first known example of which Microsoft Vista is the latest incarnation. Once again, Microsoft comes in 2nd in "innovation".
[2] Besides, of course, XEmacs.
LOL. Actually ls is an alias for the cmdlet Get-ChildItem. That's the canonical name. Other aliases are, surprise, dir and gci (no points for figuring that one out). Unlike *nix aliases PowerShell aliases are strictly aliases, i.e. they are merely alternative names for the same cmdlet. The shortcut functionality of *nix aliases are covered by PowerShell functions or filters.
The fact that the cmdlets canonical name is Get-ChildItem hints of another concept in PS: The same cmdlets can be used against multiple types of targets. The "current directory" has been extended to "current location". A location can be in anything for which there exists a PowerShell provider. It comes with (no suprise) a provider for filesystem in which "child items" will be files and/or directories. However, also the registry is exposes as a "file system", so you can set the current location to a node in a registry hive and use the exact same commands: ls, rm, cp. Other providers are certificate store, active directory, exchange, credentials store etc.
The % is actually an alias for the Foreach-Object. That cmdlet takes up to 3 script blocks: begin block, process block and end block. It starts by executing the begin block once, then executes the process block for each object in the pipeline and finally executes the end block once. If only a single block is defined (as in the above examples) it is assumed to be the "process" block. As PowerShell script is an expression language it will feed the pipeline with whatever the expressions in the block returns. During execution $_ (like in perl) is a reference to the current object being handled.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I personally enjoy the challenge of writing .BAT files that rely soley on native commands.
I'm not sure whether to laugh at you or stand up and start clapping.
It's definitely a pity you weren't around 30 or 40 years ago to do the same thing in JCL.
PS is definately late to the game. It was released in 2006 and until then advanced scripting on Windows required the hideous and verbose VBScript or something like it. But as you can tell PS is definately making a strong showing. It is consistent (easy when newly designed), extensible, feature-rich and yet simple to use when you get the concept.
As for the "some data structure" being transferred, that it not what PowerShell does. It transfers interfaces to objects through the pipeline. And those interfaces can be discovered and queried.
The Get-Member (it has the alias gm) will list the interface members (properties, methods, ...) grouped by the distinct types of objects in the pipeline.
So the command ls | gm will tell you exactly what types of objects are in the current location and what properties/methods you can use. Furthermore you can use the Format-List * (or simply fl *) to output the values of all properties of all objects.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Many Mac users have found the Unix shell hidden under Mac OS X to be quite useful.
The Divine Shell (zsh) is installed in /bin by default. /bin/sh is bash (slowly improving, but readline will never catch up to zle, which is kind of sad, actually).
I'm not nearly as fond of the Mac UI as am I of something like KDE 3 (my favorite all-time GUI), but it's growing on me and there's all the true Unix(tm) goodness underneath it. Add in a few things like XEmacs and some games like World of Warcraft and ding, you have yourself a winner.
Not to mention that stuff like Mail.app uses emacs style key bindings, you gotta love that, well, at least I do.
It won't ever meet my minimum requirements in a mission-critical system, but for something to give to my wife to use and a toy for me to play with, it works for me. Who am I kidding, keeping one's spouse happy is as mission-critical as it gets.
The guy you're referring to would be my oldest brother. I remember him carrying around homework assignments that consisted of a huge stack of punch cards. My first experience with a computer of any kind was playing tic-tac-toe on a TTY at his university. It reprinted the whole grid after every move. It seemed magical to play a game against a machine opponent. As for my brother, he's retiring this year.
But this is old news now, Windows has a CLI. I hear it's pretty powerful too. I don't spend enough time on Windows to bother learning it, but I'm glad they have it. If there are any useful ideas there, I'm sure they'll make it into Bash or ZSH or whatever.
Doubtful (that there's anything new in this so-called powershell). At least no one has posted anything so far that can't be done easier in a modern Unix shell.
I'm a little less than impressed with bash, but zsh is like manna from heaven and has been so since I first discovered it in 1990 (and it's gotten better since).
Steven Bourne deserves a lot of credit. A WHOLE lot of credit. He was the person who innovated a user interface as a full-fledged programming language and made it work. Well.
The BSD guys came later and attempted to make a csh with better programming features. .cshrc.
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
I will not detail my own personal pain and suffering as an emacs maintainer due to the gross misdesign of
At one time I was receptive towards learning csh, but openly laughed when a coworker who was attempting to show me the "power" of csh typed a very long command substitution line that was not only longer than the original command line, but had an error in it so it had to be retyped any way. (Later on, I still ported a copy of csh & tcsh sources to a System V box, of course with a subset of features (sans BSD-only features), just for the learning experience).
Of any fundamental programming interface design error, csh has probably caused more losses than any other single non-Microsoft program. (The default to printing an error message when an unsuccessful glob is "attempted" is #1).
The CLI shells that have proved successful in the long run (ksh, bash and zsh), have all been based off of Bourne's work. The Bourne Shell, even unextended from its successors is incredibly powerful. Let's see PowerShell programmers do
A BASIC interpreter:
http://www.mtxia.com/fancyIndex/Tools/Scripts/Bourne/basic.html
An Adventure game, suitable as a Unix shell:
http://www.ifarchive.org/if-archive/shells/advshell.shar.Z
I know this is fully aimed at Bourne and doesn't really cover other shells, but I would have liked to see the myth debunked that the Korn shell is a full superset of the Bourne shell. This is something which has been discussed many times on Solaris forums where some people considered it a good idea to change the shell of the root user from sh to ksh because "its a full superset". Well....
magi:/home/peter $ sh /etc/passwd ^ grep peter
magi:$PWD $ cat
peter:x:100:10:Solaris administrator:/home/peter:/bin/ksh
magi:$PWD $
I think its interesting that even now with Solaris 10 the Bourne shell is still the de-facto shell for cronjobs and common commands:
man sh(1)
NAME
sh, jsh - standard and job control shell and command inter-
preter
OMG, not being a MS kneeler, I was unaware of Powershell. Looks like more proprietary lock in and totally obfuscated command lines.
there's some truth to that. but it's not clear how you can do that without increasing the complexity of the individual tools, and making them more aware of their environment.
Explain: what would make the tools more complex?
What would make the tools more aware of their environment, and to what ill effect?
Take "find" for example. All it needs is a fool-proof way to tell a receiving process where one filename ends and another begins. If that were provided in a more consistent way across applications, one wouldn't need "-print0" or "xargs -0", you could just chain the one command to another without any special options. Simpler.
On the flip side, this means there's the logistical complexity of getting people to write their tools with one of the shell's preferred data formats in mind, and the technical complexity of making that happen. The latter is by far the less complicated issue, to my mind. Programs link in a library and most of the work is done for them. Just like we don't think about how the internal code for "printf" works, we wouldn't have to think about how the serialization layer works.
the tools model works as well as it does precisely because the individual tools are, well, dumb.
I think the tools model could work a lot better than it does. I believe people are solving problems in Perl or Python, etc., bypassing the whole suite of "small tools" precisely because these environments provide organizational structure that's missing from the shell.
again, you're right in a significant way, but something else is missed. the point is that it's "easier" for every tool. it works best in an environment where you're going to have not a dozen but a hundred tools, written by different people. as the number of tools increases, the incremental cost of increased complexity requirements goes up by that multiple.
I don't totally agree with Matz's ideas about how programming languages should be designed exclusively with the programmer in mind - I feel there has to be a balance, between the needs of the user and what the machine can provide. As it applies to this case, I'd say the needs of the user to deal with every aspect of translation steps every time they do a pipeline command outweighs the more-or-less one-time cost of writing the tools.
i'm not entirely sure what you mean here
Ad-hoc text formats are very simple to deal with when you're working with simple data structures. When those data structures need to be able to accommodate the possibility of future change without breaking existing code, or when you start using them to represent more complex structures, the burden of dealing with that organization at the byte-by-byte level for every pipeline you run becomes unreasonable.
Also, as the complexity of the text-encoded data structure becomes more complex, the simplicity and clarity that make it advantageous to encode that data as text disappear - a raw byte-dump is no longer an effective way to view it.
i'm not sure what you mean by the shell providing automatic translation. if the tools follow the above rule (that each tool assumes its output is meant to
Bow-ties are cool.
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
Bow-ties are cool.