Hi, just my 2¢ for the fanning out of pipes: if I remember correctly,
mycroftiv's hubfs (or some other software in his contrib) allowed one to
do exactly this.
hth
On 08/28/2012 09:41 PM, Dan Cross wrote:
> On Tue, Aug 28, 2012 at 8:56 PM, erik quanstrom <quans...@quanstro.net> wrote:
>>> And rc is not perfect. I've always felt like the 'if not' stuff was a
>>> kludge.
>>
>> no, it's certainly not. (i wouldn't call if not a kludge—just ugly.
>
> Kludge perhaps in the sense that it seems to be to work around an
> issue with the grammar and the expectation that it's mostly going to
> be used interactively, as opposed to programmatically. See below.
>
>> the haahr/rakitzis es' if makes more sense, even if it's wierder.)
>
> Agreed; es would be an interesting starting point for a new shell.
>
>> but the real question with rc is, what would you fix?
>
> I think in order to really answer that question, one would have to
> step back for a moment and really think about what one wants out of a
> shell. There seems to be a natural conflict a programming language
> and a command interpreter (e.g., the 'if' vs. 'if not' thing). On
> which side does one err?
>
>> i can only think of a few things around the edges. `{} and $ are
>> obvious and is some way to use standard regular expressions. but
>> those really aren't that motivating. rc does enough.
>
> I tend to agree. As a command interpreter, rc is more or less fine as
> is. I'd really only feel motivated to change whatever people felt
> were common nits, and there are fairly few of those.
>
>> perhaps (let's hope) someone else has better ideas.
>
> Well, something off the top of my head: Unix pipelines are sort of
> like chains of coroutines. And they work great for defining linear
> combinations of filters. But something that may be interesting would
> be the ability to allow the stream of computations to branch; instead
> of pipelines being just a list, make them a tree, or even some kind of
> dag (if one allows for the possibility of recombining streams). That
> would be kind of an interesting thing to play with in a shell
> language; I don't know how practically useful it would be, though.
>
>>> switch/case would make helluva difference over nested if/if not, if
>>> defaulted to fall-through.
>>
>> maybe you have an example? because i don't see that. if not works
>> fine, and can be nested. case without fallthrough is also generally
>> what i want. if not, i can make the common stuff a function.
>>
>>> variable scoping (better than subshel) would help writing larger
>>> scripts, but that's not necessarily an improvement ;-) something
>>> similar to LISP's `let' special form, for dynamic binding.
>
> (A nit: 'let' actually introduces lexical scoping in most Lisp
> variants; yes, doing (let ((a 1)) ...) has non-lexical effect if 'a'
> is a dynamic variable in Common Lisp, but (let) doesn't itself
> introduce dynamic variables. Emacs Lisp is a notable exception in
> this regard.)
>
>> there is variable scoping. you can write
>>
>> x=() y=() cmd
>>
>> cmd can be a function body or whatever. x and y are then private
>> to cmd. you can nest redefinitions.
>>
>> x=1 y=2 {echo first $x $y; x=a y=b {echo second $x $y; x=α y=β {echo
>> third $x $y}; echo ret second $x $y}; echo ret first $x $y}
>> first 1 2
>> second a b
>> third α β
>> ret second a b
>> ret first 1 2
>
> This syntax feels clunky and unfamiliar to me; rc resembles block
> scoped languages like C; I'd rather have a 'local' or similar keyword
> to introduce a variable in the scope of each '{ }' block.
>
>> you should try the es shell. es had let and some other scheme-y
>> features. let allows one to do all kinds of tricky stuff, like build
>> a shell debugger in the shell, but my opinion is that es was more
>> powerful and fun, but it didn't buy enough because it didn't really
>> expand on the essential nature of a shell. what can one do to
>> manipulate processes and file descriptors.
>
> es was a weird merger between rc's syntax and functional programming
> concepts. It's neat-ish, but unless we're really ready to go to the
> pipe monad (not that weird, in my opinion) you're right. Still, if it
> allowed one to lexically bind a file descriptor to a variable, I could
> see that being neat; could I have a closure over a file descriptor? I
> don't think the underlying process model is really set up for it, but
> it would be kind of cool: one could have different commands consuming
> part of a stream in a very flexible way.
>
> - Dan C.
>
