From: 😜 <sorosj@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] rc's shortcomings (new subject line)
Date: Tue, 4 Sep 2012 19:27:36 +0200 [thread overview]
Message-ID: <50463A08.7050204@gmail.com> (raw)
In-Reply-To: <CAEoi9W5bZE+coAaQA-Be4P_JQoB6TR31GS=gYhq=6BhHNXCRKw@mail.gmail.com>
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 <quanstro@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.
>
next prev parent reply other threads:[~2012-09-04 17:27 UTC|newest]
Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-28 8:57 [9fans] rc vs sh Rudolf Sykora
2012-08-28 9:47 ` hiro
2012-08-28 9:52 ` dexen deVries
2012-08-28 10:27 ` Rudolf Sykora
2012-08-28 13:07 ` Lucio De Re
2012-08-28 13:40 ` Rudolf Sykora
2012-08-28 14:10 ` Lucio De Re
2012-08-28 14:13 ` Kurt H Maier
2012-08-28 14:52 ` Lucio De Re
2012-08-28 15:05 ` Kurt H Maier
2012-08-28 15:18 ` Dan Cross
2012-08-28 15:30 ` Kurt H Maier
2012-08-28 15:45 ` Dan Cross
2012-08-28 17:43 ` Kurt H Maier
2012-08-28 18:20 ` Dan Cross
2012-08-28 18:26 ` Kurt H Maier
2012-08-28 18:39 ` Dan Cross
2012-08-28 18:47 ` Kurt H Maier
2012-08-28 20:42 ` Jeremy Jackins
2012-08-28 21:20 ` Dan Cross
2012-08-28 20:40 ` Uriel
2012-08-28 15:36 ` Lucio De Re
2012-08-28 15:35 ` Kurt H Maier
2012-08-28 15:41 ` erik quanstrom
2012-08-28 15:47 ` Kurt H Maier
2012-08-28 16:04 ` hiro
2012-08-28 16:05 ` Lucio De Re
2012-08-28 17:46 ` Kurt H Maier
2012-08-28 18:19 ` Lucio De Re
2012-08-28 18:18 ` Kurt H Maier
2012-08-28 20:44 ` Uriel
2012-08-31 22:24 ` Kurt H Maier
2012-08-31 23:00 ` Uriel
2012-08-31 23:15 ` hiro
2012-08-31 23:56 ` Matthew Veety
2012-09-02 15:20 ` suharik
[not found] ` <CAF9FGtS9xYBNzneNPs2eBkkqVGzn5V0FjdEWDYs_EaUu0waRvQ@mail.gmail.c>
2012-09-02 17:25 ` erik quanstrom
2012-09-02 20:40 ` suharik
2012-09-03 7:31 ` Rudolf Sykora
2012-09-03 8:22 ` dexen deVries
2012-09-03 10:04 ` suharik
2012-09-03 10:57 ` hiro
[not found] ` <CAF9FGtRdcFuuefr4q0zFBrkwaQ5a_-w4J-=xqo-MYp+phjQBaA@mail.gmail.c>
2012-09-03 13:42 ` erik quanstrom
[not found] ` <CAF9FGtTFskxpVd_CxGEKpRwfSihVjyREqWwFCmjiWksCKZoDvg@mail.gmail.c>
2012-09-03 13:46 ` erik quanstrom
2012-10-25 13:36 ` Ethan Grammatikidis
2012-10-25 13:48 ` erik quanstrom
2012-09-03 8:32 ` Balwinder S Dheeman
2012-08-28 16:06 ` tlaronde
2012-08-28 16:12 ` Aram Hăvărneanu
2012-08-28 16:32 ` tlaronde
2012-08-28 20:43 ` tlaronde
2012-08-28 18:13 ` Lucio De Re
2012-08-30 6:14 ` arnold
2012-08-30 7:41 ` Lucio De Re
2012-08-30 9:34 ` tlaronde
2012-08-30 10:26 ` Lucio De Re
2012-08-30 10:29 ` tlaronde
2012-08-30 10:50 ` Lucio De Re
2012-08-30 10:35 ` Dan Cross
2012-08-28 14:16 ` erik quanstrom
2012-08-28 14:58 ` Lucio De Re
2012-08-28 14:16 ` dexen deVries
2012-08-28 14:23 ` hiro
2012-08-28 14:34 ` hiro
2012-08-29 9:16 ` Balwinder S Dheeman
2012-08-29 15:10 ` Charles Forsyth
2012-08-29 15:22 ` hiro
2012-08-29 15:34 ` Charles Forsyth
2012-10-25 13:45 ` Ethan Grammatikidis
2012-10-25 13:56 ` dexen deVries
2012-08-28 15:09 ` Dan Cross
[not found] ` <CAEoi9W6K07ZgNS+7-oeQY3dkedW7qZLnOh79m5J7KCw7os5aEQ@mail.gmail.c>
2012-08-28 15:26 ` erik quanstrom
2012-08-28 15:40 ` Lucio De Re
2012-08-28 15:34 ` erik quanstrom
2012-08-28 18:24 ` dexen deVries
2012-08-28 18:44 ` [9fans] rc's shortcomings (new subject line) erik quanstrom
2012-08-28 19:34 ` dexen deVries
2012-08-29 0:06 ` arisawa
2012-08-29 8:12 ` dexen deVries
2012-08-28 19:41 ` Dan Cross
2012-08-28 20:14 ` Bakul Shah
2012-08-29 1:39 ` erik quanstrom
2012-08-29 1:43 ` erik quanstrom
2012-08-29 2:13 ` Bakul Shah
2012-08-29 2:23 ` erik quanstrom
2012-08-29 2:44 ` Bakul Shah
2012-08-29 4:28 ` erik quanstrom
2012-08-28 20:31 ` Aram Hăvărneanu
2012-09-04 17:27 ` 😜 [this message]
2012-08-28 19:53 ` Bakul Shah
[not found] ` <CAEoi9W5bZE+coAaQA-Be4P_JQoB6TR31GS=gYhq=6BhHNXCRKw@mail.gmail.c>
2012-08-28 20:34 ` erik quanstrom
2012-08-28 22:46 ` Bakul Shah
2012-08-29 1:28 ` erik quanstrom
2012-08-29 8:09 ` dexen deVries
2012-08-29 8:38 ` Dan Cross
[not found] ` <CAEoi9W5_r=4w5EcdrbKuqD566p=C5KvEEHg72YKzdat18En2-w@mail.gmail.c>
2012-08-29 13:57 ` erik quanstrom
2012-08-29 15:07 ` Charles Forsyth
2012-08-30 10:05 ` Dan Cross
2012-08-30 10:43 ` Charles Forsyth
2012-08-30 13:41 ` dexen deVries
2012-08-30 13:47 ` erik quanstrom
2012-08-30 14:26 ` dexen deVries
2012-08-30 14:29 ` erik quanstrom
2012-08-30 14:24 ` Dan Cross
[not found] ` <CAEoi9W6NL-zGryJnMrAX3B77bk1bOEMfkv_R7M4W052LZR4yrg@mail.gmail.c>
2012-08-30 14:26 ` erik quanstrom
2012-08-30 14:33 ` Dan Cross
[not found] ` <CAEoi9W45W0pK7MA2FvxsCVCuRcqw-JxOiEn+JQtWMo0rFcSEpg@mail.gmail.c>
2012-08-30 14:41 ` erik quanstrom
2012-08-30 14:48 ` dexen deVries
2012-08-30 15:11 ` sl
2012-08-30 15:13 ` Lucio De Re
2012-08-30 15:07 ` Burton Samograd
2012-08-30 15:13 ` Charles Forsyth
2012-08-30 15:14 ` Charles Forsyth
2012-08-30 17:02 ` Bakul Shah
2012-08-30 17:18 ` erik quanstrom
2012-08-30 20:06 ` Charles Forsyth
[not found] ` <CAOw7k5jQxJCs64ZjrXp1mU0zTUTG6p7VXYX5ykwQ8OmFATLirg@mail.gmail.c>
2012-08-30 20:10 ` erik quanstrom
[not found] ` <CAEoi9W6c2JaxrTDwR76TjuN9DeBXnO6gueOGCaEh+Fksfb9zqQ@mail.gmail.c>
2012-08-30 13:33 ` erik quanstrom
2012-08-30 14:21 ` Dan Cross
2012-08-30 14:25 ` Dan Cross
2012-08-30 14:45 ` Charles Forsyth
2012-08-30 14:55 ` Charles Forsyth
[not found] ` <CAEoi9W5AagpdK4aZCYs5tSMESU3yoMe9bmgX3GcphTcYuMq9kQ@mail.gmail.c>
2012-08-30 14:34 ` erik quanstrom
2012-08-30 14:44 ` erik quanstrom
[not found] ` <CAOw7k5i-JO=bOS8h+S0zdWghCWhSN36uFebMYnzvs=fdNQgA+g@mail.gmail.c>
2012-08-31 1:33 ` erik quanstrom
2012-10-25 14:56 ` [9fans] rc vs sh Ethan Burns
2012-10-25 15:08 ` hiro
2012-10-25 17:02 ` Gorka Guardiola
2012-10-25 17:18 ` Matthew Veety
2012-10-25 17:26 ` John Floren
2012-10-25 19:03 ` hiro
2012-10-25 19:08 ` Skip Tavakkolian
2012-08-30 15:24 [9fans] rc's shortcomings (new subject line) Lucio De Re
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50463A08.7050204@gmail.com \
--to=sorosj@gmail.com \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).