Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Bish – Shell scripting with a modern feel

github.com

Post reply on HN
Print view View original

11–20 of 44 posts

Re: Show HN: Bish – Shell scripting with a modern feel

#11

Post by cbd1984 »

s_kilk wrote: post #3
jkot wrote: post #2

Why not fish (friendly interactive shell)?

Not the OP, but I was under the impression that fish de-emphasizes shell scripting/programming and puts more emphasis on the interactive experience. It feels like bish is trying to make using bash as a programming language tolerable.

We've done this.

Back in the Day, it was BSD Unix, which used tcsh as the interactive shell and Bourne shell as the scripting shell, as tcsh had tab completion but has a scripting syntax which is harmful to sysadmins and other living things, and Bourne shell had a sane scripting language but no interactive functionality beyond cooked mode.

We developed Korn shell, Bourne-Again shell (bash), and, eventually, zsh to move beyond that idiotic experience. These days, our non-interactive scripting languages are Python, Perl, Ruby, and Ruby with a different mix of libraries, all of which have better FFI other support libraries than any shell does.

My point is, unless bish has Python-class libraries, I don't see the point of taking on the annoyance of having a scripting shell different from my interactive shell.

Re: Show HN: Bish – Shell scripting with a modern feel

#12

Post by cben »

s_kilk wrote: post #3
jkot wrote: post #2

Why not fish (friendly interactive shell)?

Not the OP, but I was under the impression that fish de-emphasizes shell scripting/programming and puts more emphasis on the interactive experience. It feels like bish is trying to make using bash as a programming language tolerable.

fish does make scripting so much saner. - $array just does the right thing, which bash can only approximate as "${array[@]}". This alone is worth everything. - (command) splits the output on newlines. - Block syntax is simpler, with exception of boolean composite conditions that need awkward begin ..; end wrapping - "everything is a command" syntax makes writing sometimes more verbose but reading easier. - prototyping at the command line then turning into a script is easier thanks to multi-line editing with indentation and syntax highlight.

There is however the portability factor. I've used fish as my only interactive shell for at least 5 years yet I rarely write a script complex enough to justify requiring users to have fish installed. Even when I write only for myself this sits at the back of my head and biases me to #!/bin/bash... From this perspective, "bish compiles to bash" made me immediately take note as a wise move.

Re: Show HN: Bish – Shell scripting with a modern feel

#13

Post by aidanhs »

For a long time I couldn't figure out why moving from bash to Python felt like such a big leap, and it was quite frustrating (path manipulation is particularly difficult).

Recently I discovered a post [1] which touches on this:

> The whole point of short code is saving human bandwidth, which is the single thing in a computing environment that doesn't obey Moore's law and doesn't double once in 18 months. Now, which kind of bandwidth is the most valuable? I'll tell you which. It's the interactive command bandwidth.

It makes the argument that syntax is actually really important in building an interactive language - '[]' is better than '()', ' ' is better than ','. And it's true, bash (and, as it happens, tcl) ruthlessly pursue this - strings don't require quotes, function calls just require spaces (rather than brackets and commas) and there's generally very little punctuation for the most common operations.

I bring this up because it's interesting to see bish has gone in the other direction (curly braces, semicolons, brackets, quoted strings) in the name of a 'modern feel'. It makes me wonder if there's a way to bring the power of python (etc) into the shell in a syntax-friendly way.

[1] http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html

Re: Show HN: Bish – Shell scripting with a modern feel

#14

Post by bishc »

aidanhs wrote: post #13

For a long time I couldn't figure out why moving from bash to Python felt like such a big leap, and it was quite frustrating (path manipulation is particularly difficult). Recently I discovered a post [1] which touches on this: > The whole point of short code is saving human bandwidth, which is the single thing in a computing environment that doesn't obey Moore's law and doesn't double once in 18 months. Now, which k…

Interesting notion! I personally am not a fan of whitespace sensitivity, but I understand why many people are. For me, after spending years writing code with curly braces and semicolons, they are effectively invisible (and thus do not seem to waste my "human bandwidth").

That being said, the choice to include those syntax features in bish was made entirely to make writing a parser easier, not for any deep philosophical reason.

Re: Show HN: Bish – Shell scripting with a modern feel

#15

Post by kevin_thibedeau »

aidanhs wrote: post #13

For a long time I couldn't figure out why moving from bash to Python felt like such a big leap, and it was quite frustrating (path manipulation is particularly difficult). Recently I discovered a post [1] which touches on this: > The whole point of short code is saving human bandwidth, which is the single thing in a computing environment that doesn't obey Moore's law and doesn't double once in 18 months. Now, which k…

I wouldn't exactly call it "modern". It seems like csh++ while avoiding its mistakes by having Bash as the backend.

Re: Show HN: Bish – Shell scripting with a modern feel

#17

Post by walterbell »

bishc wrote: post #14
aidanhs wrote: post #13

For a long time I couldn't figure out why moving from bash to Python felt like such a big leap, and it was quite frustrating (path manipulation is particularly difficult). Recently I discovered a post [1] which touches on this: > The whole point of short code is saving human bandwidth, which is the single thing in a computing environment that doesn't obey Moore's law and doesn't double once in 18 months. Now, which k…

Interesting notion! I personally am not a fan of whitespace sensitivity, but I understand why many people are. For me, after spending years writing code with curly braces and semicolons, they are effectively invisible (and thus do not seem to waste my "human bandwidth"). That being said, the choice to include those syntax features in bish was made entirely to make writing a parser easier, not for any deep philosophic…

>was made entirely to make writing a parser easier

That's called optimizing bish developer bandwidth, rather than optimizing bish user bandwidth. Neither requires philosophy :)

Re: Show HN: Bish – Shell scripting with a modern feel

#18

Post by shanusmagnus »

yramagicman wrote: post #7
basdp wrote: post #4

def printall(files) { for (f in files) { print(f); } } # cwd, ls, and cd are all builtin functions. dir = cwd(); files = ls(); print("Files in current directory $dir:"); printall(files); cd("/"); files = ls(); print("Files in root directory:"); printall(files); Whats wrong with this, much shorter Bash sequence: echo Files in current directory `pwd`: ls cd / echo Files in root directory: ls

I believe the problem comes when trying to do stuff like check to see if a file is in a directory. I'm a ZSH user myself, and my default scripting language is Python for similar reasons to the OP's for inventing Bish. I can't for the life of me figure out the syntax for an if statement, especially for things like checking if files exist. Yes, Bash or Zsh have a shorter syntax for the example, but to do something like…

I'm with you. I have written a mountain of Bash scripts to solve various one-off problems, and I'm fucked if I can ever remember the nuances from one time to the next -- when to use [], when [[]], when () or (()), when the dollar sign precedes (), etc. Every single time I have to do anything in Bash I have to re-learn Bash. I suppose I keep using it because, even with having to re-learn every single element of Bash coding every time, it's still faster for doing a bunch of filesystem stuff for me. But god, I hate it. I can't think of a computer technology I hate more. I hate it more than R, and I really hate R too, for some of the same reasons.

I keep intending to learn Perl really well, which I think could absorb much of Bash, and also Awk and Sed, and then there would be only one thing I needed to know for this kind of work, and I might use it enough to remember the various weird syntactic bits from one month to the next. But I never quite get over the hump.

Re: Show HN: Bish – Shell scripting with a modern feel

#19

Post by mhw »

Recently I've returned to writing scripts using Byron Rakitzis' reimplementation of the Plan 9 rc shell, and been very happy with the results. It doesn't have the idiosyncrasies that bash has, and which seem to be a motivation for bish. Variables are not rescanned when expanded so you don't have to remember hacks like '"$*"', for example. At the same time it adds some features which really help when writing scripts (a list type and a pattern matching operator for example). And yet it still feels like a shell rather than a 'proper' scripting language: pipes and redirection are still core parts of the language rather than things you have to program using the standard library.

It's included in the standard Ubuntu repositories (http://packages.ubuntu.com/trusty/shells/rc) and it looks like it's in homebrew as well. I'd recommend giving it a try. The original Plan 9 paper describing rc is a good place to start and a good read, although you should be aware that Rakitzis' version made some minor changes to the syntax (a more usual if...else instead of Duff's 'if not') and dropped some Plan 9 specific pieces.

Re: Show HN: Bish – Shell scripting with a modern feel

#20

Post by lobster_johnson »

aidanhs wrote: post #13

For a long time I couldn't figure out why moving from bash to Python felt like such a big leap, and it was quite frustrating (path manipulation is particularly difficult). Recently I discovered a post [1] which touches on this: > The whole point of short code is saving human bandwidth, which is the single thing in a computing environment that doesn't obey Moore's law and doesn't double once in 18 months. Now, which k…

I tend to write shell scripts in Ruby even more often than bash. I'm proficient in both, but I find that the larger the script, the more I'm affected by the lack of language support in bash, and the many oddities such as the many problems with quoting and string splitting and the hacks/special mechanisms needed to work around them.

Even though bash has some "modern" features, they're typically a bit weird and hard to remember: bash has arrays, for example, but the syntax is bizarre; you can write functions, but you can't declare the parameters, only access them as $1, $2, etc.; and so on. Occasionally I have to look up some expression syntax (like which bracket syntax to use for arithmetics, or whether "if" should have one or two brackets, and whether it's [[ a && b ]] or [[ a ]] && [[ b ]]) just because it's so damn different. It's painfully obvious that bash wasn't planned; so much of its evolution can be felt in the layers of hacks.

And with Ruby it's much easier to refactor to do things like logging (eg., when spawning a sub-command, only show its output if it fails), or provide cleanup (express your script with the command pattern, with commands that know how to commit and undo themselves), or use existing libraries.

Ruby's syntax — the ability to omit parantheses, the support for running shell commands with backticks — makes it particularly suited. For example:

    if [ -e ./somefile ]; then
      ./somecommand ./somefile
      (cd ./somedir && make)
      installdir=`getsomeconfig`
      cp build/mybinary $installdir/bin
    fi
In Ruby:

    if File.exist? "somefile"
      `./somecommand ./somefile`
      Dir.chdir 'somedir' do
        `make`
      end
      installdir = `getsomeconfig`
      cp "build/mybinary", "#{installdir}/bin"
    end
The last line requires that you initially do:

    require 'fileutils'; include FileUtils
Now you have a bunch of utilities (cd, cp, mv, mkdir, mkdir_p, etc.) as global Ruby methods.
Post reply on HN