Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 7/1/83; site rlgvax.UUCP Path: utzoo!linus!philabs!seismo!rlgvax!jeff From: jeff@rlgvax.UUCP Newsgroups: net.unix-wizards Subject: > and >> in rsh Message-ID: <753@rlgvax.UUCP> Date: Sun, 3-Jul-83 14:50:43 EDT Article-I.D.: rlgvax.753 Posted: Sun Jul 3 14:50:43 1983 Date-Received: Mon, 4-Jul-83 04:25:00 EDT Organization: CCI Office Systems Group, Reston, VA Lines: 33 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