[HN Gopher] Ambitions for a Unix Shell
___________________________________________________________________
Ambitions for a Unix Shell
Author : luu
Score : 30 points
Date : 2020-01-26 05:54 UTC (17 hours ago)
(HTM) web link (www.oilshell.org)
(TXT) w3m dump (www.oilshell.org)
| skrebbel wrote:
| Mostly off topic, but I've never understood why shells are
| designed to have this weird dual use case of both being easy to
| type into a command prompt, and being easy to write 40+ line
| scripts in. Why does that need to have the exact same syntax?
| This is the root cause of why bash (and batch and etc etc etc)
| are so terrible to script in (and why powershell is so terrible
| to type into a terminal). This weird shit like [ being a command,
| and having to think long and hard about exactly when variables
| are replaced and when globs are executed and how errors happen..
| It's just pretty pointless.
|
| Like, if you write a script using Python or Ruby or Perl or
| whatever, there's easy ways to call into the shell. Often it's
| even built-in, like using backticks `echo like this`. These
| languages aren't designed for shell scripting but even they are
| often easier and cleaner than a bash script. It could be much
| better thoughk I bet.
|
| I'd love to have a language that is easy and familiar to type
| into a terminal (and thus, sufficiently bash-like probably),
| while being significantly easier to write scripts in. You could
| require the script to have a bit more syntax, a bit more
| structure, but essentially have the same semantics as what you'd
| type on the command line, and you'd have the best of both worlds.
| If well designed, it'd still "feel" like the same thing (much
| like how all JS programmers immediately grokked Coffeescript when
| it came out, because it really was just JS); everything you'd
| learn on the command line, you'd be able to apply in a script and
| vice versa. The script would just require more structure and thus
| provide more comfort (good error messages, editor support, etc).
|
| For example, globbing. The idea that the shell expands " _.foo "
| into a list of files, before evaluating the command, is handy,
| but it's also an enormous footgun. What if on the terminal it
| would do that, but when scripting, you'd be required to write
| `glob("_.foo")` or else it'd error out? THat would force you to
| clearly control when the expansion happens, it would let you
| assign it to a variable in a readable way etc. Imagine similar
| stuff for argument lists, escaping, variable substitution, etc -
| all the magic available on terminal, but contained in the script.
|
| Does this exist? I'd love to have it.
| chubot wrote:
| (author here) Your first and third paragraph seem to be in
| conflict? I have heard the feedback that an interactive shell
| and a programming language should be different, which I
| disagree with.
|
| (For one, shell is already used as a programming language, so
| the ship has sailed. Also I use shell in the Lisp tradition:
| build your program up with a REPL.)
|
| But yes Oil is designed to "give the best of both worlds" as
| you say in the third paragraph.
|
| This recent post will probably give you the best idea of it:
|
| http://www.oilshell.org/blog/2020/01/simplest-explanation.ht...
|
| Rather than echo $mystr # silently splits
| echo "mystr" # no split
|
| In Oil, it's: echo $mystr # no split
| by default echo @split(mystr) # opt in explicitly
|
| This is enabled with options so existing shell scripts work.
| Also @split isn't really idiomatic since you would likely use
| arrays, but it could be useful for porting.
|
| I've also thought of adding a more explicit alternative for
| glob, but I actually like the shorter syntax here:
| echo *.py echo @glob('*.py') # not implemented but is
| consistent
|
| But I'm probably going to implement this safety feature
|
| https://github.com/oilshell/oil/issues/552
|
| to solve the well known issue where files that look like flags
| can confuse code and data. e.g. 'rm *' with a file named '-rf'.
| acqq wrote:
| In "rather than" part
|
| > echo "mystr" # no split
|
| You probably meant
|
| echo "$mystr" # no split
|
| But echo is not good for these examples as for it the split
| doesn't matter and can't be detected, whereas for other
| commands (or even calls of functions) it indeed can matter.
|
| This example, I think, illustrates the differences (as
| present in the current shells) better: f()
| { echo "param 1: |$1|" echo "param 2:
| |$2|" } x= y=33 f "$x"
| "$y" f $x $y #param 1: || #param
| 2: |33| #param 1: |33| #param 2: ||
| frou_dh wrote:
| > I've never understood why shells are designed to have this
| weird dual use case of both being easy to type into a command
| prompt, and being easy to write 40+ line scripts in.
|
| It was probably less about that explicitly being considered the
| optimum design, and more about it being irresistible to save a
| lot of labor by getting 2 for the price of 1.
| analognoise wrote:
| Spot on.
|
| You end up building a lot of things with hammers, saws and
| nails when all you have are hammers, saws and nails.
| GSGBen wrote:
| (Replied to op instead of comment):
|
| Is your complaint about PowerShell the verbosity? Because I
| love its approach to this: full verbosity is the default (great
| for scripts), then terminal usage is improved by aliases
| (ForEach-Object is just %), great autocomplete via psreadline,
| and automatic parameter shortening: -re and -fo are
| automatically understood as -Recurse and -Force. Honestly makes
| every other shell a pain to use now for me.
|
| Also having everything be object based is just...I have no idea
| how I lived before.
| boona wrote:
| >What languages and tools does Oil aim to "replace"? >bash, awk,
| make, Python 2
|
| What will in fact happen: It says here on your resume that you
| know bash, awk, make, and python 2, but do you know Oil as well?
| chubot wrote:
| "replace" is in quotes for a reason :) The rest of the post
| gives some more color on it.
| keeganpoppen wrote:
| not only is this an extremely exciting project that I've been
| following for what feels like years, but there is such a
| tremendous richness of stuff only tangentially related to the
| project that the author has collected as well (one example:
| https://github.com/oilshell/oil/wiki/ExternalResources). this is
| clearly such a well-organized, thoughtful endeavor that i have
| absolute faith that great things will come of it. and he's an
| excellent writer to boot!
| jerf wrote:
| "So the biggest change is that Oil will be based on strings (and
| arrays of strings) like shell"
|
| I would advise the author have a look at the internals of Tcl,
| not because you should copy all the sophisticated features
| immediately, but because it demonstrates a way to have both
| "everything is a string" _and_ "advanced data structures" in a
| relatively principled manner. You don't have to start out with
| all the optimizations from day one but I always find it helpful
| to have a look down the road in cases like this, and make sure
| that if this sort of thing interests you that you don't
| accidentally make it impossible later.
| chubot wrote:
| (author here) Yeah I appreciate a lot of things about Tcl,
| which is basically Lisp + shell (I think Ousterhout even said
| that?) I read most of the thick book about it even though I
| don't regularly program in Tcl.
|
| A bunch of people have brough up Tcl, and as noted here [1],
| Oil looks superficially like it because it has proc and set
| keywords.
|
| The biggest difference is that Oil isn't homoiconic in the
| sense that Tcl is. I believe that implies a lot of dynamic
| parsing which I'm staying away from [2].
|
| And of course Oil is a compatible Unix shell, which imposes a
| bunch of constraints. Namely the 'proc' is "isomorphic" to a
| process -- it takes argv and returns an exit code, and it can
| be transparently put in pipelines. I wrote 3 years ago about
| this powerful form of composition [3] and I wish I had finished
| that :-/
|
| [1]
| https://www.reddit.com/r/oilshell/comments/esqyaw/ambitions_...
|
| [2] http://www.oilshell.org/blog/2019/02/07.html
|
| [3] http://www.oilshell.org/blog/tags.html?tag=shell-the-good-
| pa...
| [deleted]
| enriquto wrote:
| This is some of the most exciting stuff happening in the unix
| world these days.
|
| My mind was blown after reading two posts on Oil's author blog, a
| few years ago:
|
| * Shell has a Forth-like Quality:
| https://www.oilshell.org/blog/2017/01/13.html
|
| and
|
| * Pipelines Support Vectorized, Point-Free, and Imperative Style:
| https://www.oilshell.org/blog/2017/01/15.html
|
| Warning: these writings can change your view on the shell
| language. Now you probably think, as many of us did, that shell
| is a cute little hack, useful for one-off throwaway stuff, but
| not really fit for serious work. Afterwards, you will start to
| see the shell as a glorious, essential element of our
| civilization, worth of respect and deserving our careful
| attention. Pipes are an essential programming tool that must be
| supported by the core language and not by a library construct (as
| in python).
___________________________________________________________________
(page generated 2020-01-26 23:00 UTC)