why Unix?

[Steven Schveighoffer]

On Tue, 07 Apr 2009 18:17:12 -0400, Jarrett Billingsley  
<jarrett.billingsley at gmail.com> wrote:

> On Tue, Apr 7, 2009 at 3:30 PM, Steven Schveighoffer
> <schveiguy at yahoo.com> wrote:
>
>>> And regarding using it as an user shell: there's an interactive command
>>> line interpreter.
>>
>> if you type ls, does it work, or do you have to type __run__("ls") or
>> whatever?
>
> I think it's things like this that are the reason a lot of attempts at
> turning general-purpose scripting languages into shells has failed.
> Despite the horrid mess that is bash's syntax, the syntax for simple
> commands is.. simple.  Elegant, to a point.
>
> So what I've been considering is creating a modified version of MiniD.
>  All that would be required is some modifications to the syntactic
> analyzer and a small library of functionality for very common shell
> tasks.  The important part is the modifications to the syntactic
> analyzer.
>
> So suppose you started up this minishell or mdsh or whatever it's called.
>
> $ mdsh
>> _
>
> OK, go ahead and type some stuff.
>
>> ls
> foo.d    bar.d    baz.d
>> ls -a
> .    ..    foo.d    bar.d    baz.d
>> grep "hello" | sort
> a: hello!
> b: hello!
>> _
>
> Uh, ok, so it looks just like bash.  What's happening under the hood
> is that when in interactive mode, the compiler is in "bash mode."  It
> parses each line as a bash statement.  But it's not actually bash: all
> it's doing is parsing the line and turning it into some kind of MiniD
> code under the hood.  so `grep "hello" | sort` becomes instead
> "shell.exec("grep", "hello").pipe("sort")", or something like that.
> Then that is compiled into MiniD code and executed.  The shell.exec
> function just spawns a new process and returns some process object
> which can be piped to another one.
>
> Then you have a simple "escaping" mechanism to switch between MiniD
> mode and bash mode.  Something like %.
>
>  > %foreach(file; shell.ls())
> .. {
> ..      writeln("processing file ", file)
> ..      %something $file
> .. }
> processing file foo.d
> processing file bar.d
> processing file baz.d
>  > _
>
> There.  Now you have sane syntax for complex language constructs, but
> it's still simple to escape into bash mode to do shell-y stuff.
> Notice the "$file", which is a signal to the compiler to convert
> 'file' as a variable reference rather than as a string argument to the
> command.
>
> (It also follows that if you wrote a full shellscript, in a .mdsh file
> or something, the compiler would, when compiling it, start in MiniD
> mode by default so you wouldn't have to escape every statement with a
> %.)
>
> I know Alex wants to see this happen :P

This reminds me of jsp, where java is intermixed into html.  When you want  
HTML, it's there, when you want java, you simply escape into java.

It's not a bad idea.  Not sure I'd use it, but I'd certainly try it :)  I  
certainly could deal with D-like syntax more than python syntax.

I'm a little confused on the escaping.  In one example, it looks like %  
turns MiniD alternately on and off, yet you say you'd have to escape every  
line in a script file?

If you meant the "on/off" style, the escaping should be more like  
open/closing (e.g. %< minid code >% ).  Otherwise, it'd be hard to tell in  
the middle of the file whether you're in miniD or bash syntax.

You should also be able to alias any miniD function that takes an array of  
strings to a shell "command".  This would allow you to have a selected  
overlap between miniD and your PATH's namespace.  Something like:

> %shell.alias("foo", &foo)
> foo a b "c d e"

which would be equivalent to calling foo("a", "b", "c d e"), even if there  
was a foo command in your path.

BTW, never used miniD, so I don't know what's already possible.

-Steve