jeff@rlgvax.UUCP (07/03/83)
As a former victim of the Bourne restricted shell, I found it hard to understand why > and >> were prohibited. They could easily be replaced with tee and cat (though doing this was far less efficient). It seemed as if the sole effect of the > restriction was to force the rsh victim to create extra processes. Incidentally, why have >, and < in the shell at all? You can do it all with "optimized" pipes. The distinction at the shell level between processes and data can be eliminated by having a command path which turns out not to be executable be treated as input or output from a file, depending on which side of the pipe it is on. This would simplify shell syntax. That is, uniq < data > output could be written as data | uniq | output and cat a b c | tee hold | sort -n > sorted as (a; b; c) | hold | sort -n | sorted Some complexities do arise here. Syntax would be needed to force an executable to be treated as data. The use of the path variable might (or might not) usefully be altered. The csh would need to have its hashing rethought. >> would want some other syntax (such as |>). And the shell would have to be a little bit smart about directly hooking piped files to stdin where possible, rather than creating an extra process and pipe. Jeffrey Kegler CCI Office Systems Division (formerly RLG) ...{allegra,seismo,mcnc,lime,we13,brl-bmd}!rlgvax!jeff
geo@watarts.UUCP (07/05/83)
In his original article Jeff Kegler asks why not eliminate < and > from the shell and have it determine what you mean by context. I don't see any advantadge in Jeff's scheme. It seems to me his scheme would break down over shell procedures. he give the example: cat a b c | tee hold | sort -n > sorted could be written as (a; b; c) | hold | sort -n | sorted If a, b, or c were shell procedures, acording to his syntax they would be invoked rather than cat'ed.