Elvish = Expressive Programming Language + Versatile Interactive Shell


Elvish: Expressive Programming Language + Versatile Interactive Shell

CI status FreeBSD test status gccgo test status Test Coverage Go Report Card GoDoc Twitter

Elvish is an expressive programming language and a versatile interactive shell, combined into one seamless package. It runs on Linux, BSDs, macOS and Windows.

Despite its pre-1.0 status, it is already suitable for most daily interactive use.

Visit the official website https://elv.sh for prebuilt binaries, blog posts, documentation and other resources.

User groups (all connected thanks to Matrix): Gitter Telegram Group #elvish on freenode #users:elves.sh

Building Elvish

Most users do not need to build Elvish from source. Prebuilt binaries for the latest commit are provided for Linux amd64, macOS amd64, Windows amd64, and many other platforms.

To build Elvish from source, you need

  • A supported OS: Linux, {Free,Net,Open}BSD, macOS, or Windows.

    NOTE: Windows support is experimental, and only Windows 10 is supported.

  • Go >= 1.15.

To build Elvish from source, follow these steps:

# 1. Start from any directory you want to store Elvish's source code
# 2. Clone the Git repository
git clone https://github.com/elves/elvish
# 3. Change into the repository
cd elvish
# 4. Build and install Elvish
make get

This will install Elvish to ~/go/bin; you might want to add it to your PATH.

To install it elsewhere, override GOBIN in the make command:

make get GOBIN=$PWD # Install to the repo root (use $pwd if running in Elvish)
make get GOBIN=/usr/local/bin # Install to /usr/local/bin

Note that GOBIN must be an absolute path.

Packaging Elvish

See PACKAGING.md for notes for packagers.

Contributing to Elvish

See CONTRIBUTING.md for notes for contributors.

  • SIGPIPE should not be considered a failure for data-producers in a pipeline

    SIGPIPE should not be considered a failure for data-producers in a pipeline

    This is debatable perhaps, and one could argue that it's a bug in most Unix commands that currently exist: But I think SIGPIPE should not be considered an error.

    The rationale is this: It's not uncommon to create pipelines that will terminate one or more of their commands with SIGPIPE - and typically this does not mean that anything has failed, but rather that one of the processes in the pipeline has stopped consuming values, and the program that was producing values for that process terminated as a result. I think it's fair to argue that these producers should not return an error status in this case, but the usual (default, in fact!) behavior is to terminate on an unhandled SIGPIPE, or catch the signal and terminate with the equivalent error code.

    So for instance, this produces a SIGPIPE: e:sort --random-sort /usr/share/dict/american-english | e:head -n 10 (Produce a list of random words)

    "head" reads the first 10 lines of inputs and then terminates, breaking the pipe. "sort" then receives SIGPIPE (or possibly, equivalent information via another means, depending on implementation) next time it writes to its output. Being unable to write out more data, it terminates. This is not an "exception"al condition, but rather a fundamental part of how stream processing works in shell pipelines.

    On the flip side of this argument: a "graceful" shutdown of a pipeline is not the only condition that can produce a SIGPIPE. A program could fail with SIGPIPE due to a purely internal error, or due to a connection loss, etc. This is why I consider my argument "debatable" and say "it could be considered a bug in the programs called by the shell" - If the SIGPIPE occurs in a scenario where it should not be treated as an error, then arguably "e:sort" and so on should not terminate with a non-zero exit code. I think it's a fair argument that people should simply recognize this and capture errors or use try/catch when running a pipeline that could reasonably be expected to SIGPIPE. But it's very typical for SIGPIPE to simply indicate that a pipeline has shut down. I don't think there is a set of criteria that can be applied to reliably distinguish between a "pipeline SIGPIPE" and an "internal error SIGPIPE" - the sequence in which processes terminate isn't a reliable indicator because SIGPIPE is triggered by the consumer closing its input, which could happen before termination - and if we said "SIGPIPEs aren't exceptions if they're generated by producers in a pipeline" there's always the chance that we're suppressing some true internal failure.

    (I think treating process exit codes as exceptions is a good idea, though a challenging one to resolve against a tradition in which exit codes mostly don't matter...)

    opened by zakukai 60
  • Consider following XDG base directory spec

    Consider following XDG base directory spec

    The docs show the default config location is ~/.elvish/rc.elv. Please consider following the XDG base directory spec. The default location would then be ~/.config/elvish/rc.elv.

    Moving configs into a folder helps reduce clutter. In the last few years many tools have slowly been adding support: XDG Base Directory support. For comparison, fish shell uses ~/.config/fish/config.fish as its startup file, and lazy-loaded functions go in ~/.config/fish/functions/.

    On macOS most tools generally continue using ~/.config as the default location. However, should you choose to follow Apple's guidelines (macOS Library Directory Details), you would use ~/Library/Application Support/elvish/ to place any configs, data, and files. Two other commonly used folders are Caches (~/Library/Caches/elvish/) and Logs (~/Library/Logs/elvish/).

    opened by cesarandreu 25
  • Support for 'cd -'

    Support for 'cd -'

    In bash, cd - expands to cd $OLDPWD, where $OLDPWD holds the previous working directory. It would be nice to have this in elvish. zsh extends on this by providing cd -N (where N is in integer) to access arbitrary 'directory history' items, which may also be worth adding.

    opened by ALSchwalm 22
  • `except` must be in the same line as `}`

    `except` must be in the same line as `}`

    This code is ok:

    try { 
        fail bad 
    } except e {            # <= ok!
        put $e 

    But if you move except to the next line

    try { 
        fail bad 
    except e {              # <= here
        put $e 

    you get this very misterious error:

    # compilation error: variable $e not found
    # /home/tfga/sbin/exceptBug.elv, line 11:     put $e

    Would it be possible to lift this restriction?

    In any case, the error message is very puzzling. It took me a long time to figured out what exactly I had done wrong.

    opened by tfga 21
  • Require explicit variable declarations with

    Require explicit variable declarations with "var"

    Currently, variables do not require explicit declarations; a variable is created when they get assigned for the first time. One drawback of this approach is that you can accidentally assign variables in outer scopes when you intend to make a new variable, like

    i = 10
      # in a deeply-nested scope
        i = 100

    This can be a nuisance but most of the time it is not too problematic.

    What is problematic, though, is that this makes introducing new builtin variables hard. For instance, today there is no builtin variable called foo, so foo = lorem always creates a new variable. But if a builtin variable foo is to be introduced, the semantics of foo = lorem changes to modifying the builtin variable, which likely has some unintended side effect.

    Hence I would like to make variable declarations explicit: use let for readonly variables and var for read-write variables. The syntax will simply be:

    let x = foo # creates readonly variable x
    var y = bar # creates read-write variable y

    Since this is a far-reaching and mechanical change, a script should be provided for rewriting code to use the new syntax. Timeline:

    1. Before release of 0.12, new syntax is supported and an automatic rewrite tool is provided.
    2. Before release of 0.13, old syntax is removed;

    Edit: as of 2020-08-17, the plan has been changed to support the new syntax in 0.15.0 and remove the old syntax in 0.16.0.

    The proposed declarator for immutable variables has also been changed to val, instead of let.

    Edit: as of 2021-10-12, support for val is tracked separately in #1407.

    opened by xiaq 20
  • RFC: Add a simpler control struct for executing a loop N times?

    RFC: Add a simpler control struct for executing a loop N times?

    The only aspect of Elvish that still annoys me is writing simple loops to be executed N times. Go has a C like construct for this case:

    for i := 0; i < 10; i++ {

    While in Elvish that would be written thusly:

    for i [(range 10)] {

    The Elvish formulation is more succinct. But it's also considerably less efficient (especially for large values of N) since it requires instantiating a list then ranging over it. I'm not suggesting adding the Go syntax but it would be nice if there was an even simpler, more efficient, way to perform this common operation. The simplest, most Elvish, solution I can think of is to augment the builtin range command to accept an optional argument that takes a lambda. Thus allowing the above to be written like this:

    range 10 {|i|
    opened by krader1961 18
  • Use XDG runtime directory on Unix when present

    Use XDG runtime directory on Unix when present

    This pull-request uses $XDG_RUNTIME_DIR on Unix to store the runtime files. If $XDG_RUNTIME_DIR is not set it falls back to the old location (e.g.: /tmp/elvish-$uid).

    This is a small first step towards XDG compliance on Unix (#383).

    opened by vially 18
  • Recognize Shift-Alt-arrow and Cmd-Alt-arrow on iTerm2

    Recognize Shift-Alt-arrow and Cmd-Alt-arrow on iTerm2

    If I hit Shift-Alt-Up, I get this error:

    error when reading terminal: bad CSI: "\x1b[1;10A"

    similar error messages appear with the other arrow keys (with the final A replaced by B, C or D).

    Something similar happens with Command-Alt arrow combinations (with 10 replaced by 9).

    This is in iTerm2 on a Mac. I assume the resulting codes are more or less standard ones. It would be good if they were added to elvish's repertoire of recognized byte sequences, so we can bind to these keystrokes.

    opened by hanche 18
  • sort function

    sort function

    It would be nice to have a sorting function in Elvish (maybe named something else, to avoid conflicting with the standard Unix sort command). Ideally it would support structured data, and allow specifying a sorting function (like Clojure's sort-by).

    opened by zzamboni 18
  • Daemon connectivity problems

    Daemon connectivity problems

    after installing elvish on bash/windows subsystem for linux I am greeted with this warning:

    warning: socket exists but not responding version RPC: dial unix /tmp/elvish-1000/sock: connect: connection refused

    followed by this error:

    Failed to initialize command history. Disabled.

    this question is did I do something incorrectly, or does this stem from the wsl?

    opened by southpawflo 18
  • Support arbitrary-precision numbers

    Support arbitrary-precision numbers


    • No overflow
    • More intuitive: + 0.1 0.2 is 0.3, instead of 0.30000000000000004


    • math/big does not provide math functions like sin, log; they are only available for float64;
    • Performance (will we ever be doing a lot of number crunching in elvish)?
    opened by xiaq 18
  • exploding breaks on @varname vars

    exploding breaks on @varname vars

    note the comments

    ~> echo $version
    ~> var foo = [a b c]
    ~> var '@bar' = [x y z]
    ~> echo $foo $'foo' [email protected]  # ok
    [a b c] [a b c] a b c
    ~> echo [email protected]'foo'  # imo: should work
    compilation error: 5-7 in [tty]: variable $ not found
    compilation error: variable $ not found
    [tty 5], line 1: echo [email protected]'foo'
    ~> echo $'@foo' # should error with 'variable $"@foo" not found'
    a b c
    ~> echo [email protected]   # should error with 'variable $bar not found'
    [x y z]
    ~> echo $'@bar'
    [x y z]
    ~> echo $'@@bar'
    compilation error: 5-13 in [tty]: variable [email protected] not found
    compilation error: variable [email protected] not found
    [tty 10], line 1: echo $'@@bar'
    ~> echo [email protected]'@bar'
    compilation error: 5-7 in [tty]: variable $ not found
    compilation error: variable $ not found
    [tty 11], line 1: echo [email protected]'@bar'


    opened by marcusatiliusregulus 0
  • Flakey src.elv.sh/pkg/edit unit tests

    Flakey src.elv.sh/pkg/edit unit tests

    I see transient unit test failures of src.elv.sh/pkg/edit on my VMs on a regular basis. The following examples are from three different VMs testing the same commit for the first time after booting and connecting to each VM. Re-running the tests succeeds. Clearly there is something about these tests that is overly dependent on the speed of the target system at executing the code under test. Whether one or more timeouts needs to be increased or a synchronization mechanism introduced is unclear.

    For example:

    ok      src.elv.sh/pkg/diag     (cached)
    --- FAIL: TestMinibuf (0.64s)
        minibuf_test.go:19: wanted buffer not shown:
            Width = 50, Dot = (0, 6)
            │~> put$                                           │
        minibuf_test.go:19: Last buffer: Width = 50, Dot = (0, 6)
            │~> put$                                           │
    FAIL    src.elv.sh/pkg/edit     14.283s


    --- FAIL: TestMinibuf (0.58s)
        minibuf_test.go:19: wanted buffer not shown:
            Width = 50, Dot = (0, 6)
            │~> put$                                           │
        minibuf_test.go:19: Last buffer: Width = 50, Dot = (1, 31)
            │~> $                                              │
            │ MINIBUF  edit:insert-at-dot pu$                  │
    FAIL    src.elv.sh/pkg/edit     19.600s


    --- FAIL: TestNavigation_UsesEvalerChdir (0.76s)
        navigation_test.go:160: wanted buffer not shown:
            Width = 50, Dot = (0, 7)
            │~/d/e> $                                          │
        navigation_test.go:160: Last buffer: Width = 50, Dot = (0, 7)
            │~/d/e> $                                          │
    --- FAIL: TestPrompt_ValueOutput (0.61s)
        prompt_test.go:18: wanted buffer not shown:
            Width = 50, Dot = (0, 5)
            │#13> $                                            │
        prompt_test.go:18: Last buffer: nil
    FAIL    src.elv.sh/pkg/edit     8.534s
    opened by krader1961 0
  • Correctly encode strings with invalid UTF-8

    Correctly encode strings with invalid UTF-8

    In addition to fixing the encoding bugs standardize on \xNN notation for bytes rather than \uNNNN; e.g., \x00 rather than \u0000.

    Also, update the documentation for double-quoted strings to include the \e sequence.

    Fixes #1528

    opened by krader1961 2
  • crash: unexpected rune '`'

    crash: unexpected rune '`'

    affected version



    Crash on completion related #1511

    steps to reproduce

    echo `<TAB>


    goroutine 1 [running]:ty]: unexpected rune '`' 
            src.elv.sh/pkg/sys/dumpstack.go:10 +0x66 
            src.elv.sh/pkg/shell/interact.go:141 +0x5a 
    panic({0x5603fb578680, 0xc0001b5818}) 
            runtime/panic.go:838 +0x207 
    src.elv.sh/pkg/edit/complete.completeVariable({0x0?, 0x0?, 0x0?}, {{0x5603fb598378?, 0xc0001321c0?}, 0xc000474c00?, 0xc0004984e0?}) 
            src.elv.sh/pkg/edit/complete/completers.go:149 +0x2c6 
    src.elv.sh/pkg/edit/complete.Complete({{0xc0000aa300?, 0xc00021c000?}, 0x0?}, {{0x5603fb598378?, 0xc0001321c0?}, 0xc000474c00?, 0xc0004984e0?}) 
            src.elv.sh/pkg/edit/complete/complete.go:91 +0x256 
    src.elv.sh/pkg/edit.completionStart({0x5603fb5986b0, 0xc00021c000}, {0x5603fb595218, 0xc000212db0}, {{0x5603fb598378?, 0xc0001321c0?}, 0xc000474c00?, 0xc0004984e0?}, 0x1) 
            src.elv.sh/pkg/edit/completion.go:180 +0x171 
            src.elv.sh/pkg/edit/completion.go:267 +0x70 
    reflect.Value.call({0x5603fb515900?, 0xc000212e10?, 0x5603fb1a3e4d?}, {0x5603fb47b462, 0x4}, {0x0, 0x0, 0xc00?}) 
            reflect/value.go:556 +0x845 
    reflect.Value.Call({0x5603fb515900?, 0xc000212e10?, 0x2000?}, {0x0, 0x0, 0x0}) 
            reflect/value.go:339 +0xbf 
    src.elv.sh/pkg/eval.(*goFn).Call(0xc00021b650, 0xc000162000, {0x0, 0x0, 0x0?}, 0xc00007d290) 
            src.elv.sh/pkg/eval/go_fn.go:247 +0xb46 
    src.elv.sh/pkg/eval.(*Evaler).Call(0x5603fb1a156d?, {0x5603fb594af8, 0xc00021b650}, {{0x0, 0x0, 0x0}, 0xc00007d290, {0x5603fb47f6ed, 0x10}}, {{0xc0000ac2b8, ...}, ...}) 
            src.elv.sh/pkg/eval/eval.go:434 +0x376 
    src.elv.sh/pkg/edit.callWithNotifyPorts({0x5603fb595f78, 0xc000078900}, 0x1?, {0x5603fb594af8, 0xc00021b650}, {0x0, 0x0, 0x0}) 
            src.elv.sh/pkg/edit/key_binding.go:67 +0x1ef 
    src.elv.sh/pkg/edit.mapBindings.Handle({{0x5603fb595f78, 0xc000078900}, 0xc0001321c0, {0xc00000ed38, 0x1, 0x1}}, {0xc00000ebd0?, 0xc0004f3700?}, {0x5603fb5950d8, 0xc000276428}) 
            src.elv.sh/pkg/edit/key_binding.go:41 +0x10b 
    src.elv.sh/pkg/cli/tk.(*codeArea).handleKeyEvent(0xc00021c100, {0x4f3798?, 0xc0?}) 
            src.elv.sh/pkg/cli/tk/codearea.go:297 +0xdc 
    src.elv.sh/pkg/cli/tk.(*codeArea).Handle(0xc00021c000?, {0x5603fb5950d8?, 0xc000276420?}) 
            src.elv.sh/pkg/cli/tk/codearea.go:172 +0x72 
    src.elv.sh/pkg/cli.(*app).handle(0xc00021c000, {0x5603fb55d620?, 0xc000276420}) 
            src.elv.sh/pkg/cli/app.go:226 +0x165 
            src.elv.sh/pkg/cli/loop.go:129 +0x1ac 
            src.elv.sh/pkg/cli/app.go:475 +0x49a 
            src.elv.sh/pkg/edit/editor.go:113 +0x22 
    src.elv.sh/pkg/shell.interact(0xc0001321c0, {0xc000010010, 0xc000010018, 0xc000010020}, 0xc00020fda0) 
            src.elv.sh/pkg/shell/interact.go:100 +0x846 
    src.elv.sh/pkg/shell.(*Program).Run(0xc00007d950, {0xc000010010, 0xc000010018, 0xc000010020}, {0xc000020200, 0x0, 0x0}) 
            src.elv.sh/pkg/shell/shell.go:98 +0x2db 
    src.elv.sh/pkg/prog.Run({0xc000010010, 0xc000010018, 0xc000010020}, {0xc000020200, 0x1, 0x1}, {0x5603fb5967e8, 0xc00000e6c0}) 
            src.elv.sh/pkg/prog/prog.go:83 +0x3d4 
            src.elv.sh/cmd/withpprof/elvish/main.go:17 +0x1c5 
    goroutine 6 [chan receive]: 
            src.elv.sh/pkg/eval/port.go:96 +0x3a 
    created by src.elv.sh/pkg/eval.getBlackholeChan 
            src.elv.sh/pkg/eval/port.go:95 +0x6a 
    goroutine 7 [syscall]: 
            runtime/sigqueue.go:151 +0x2f 
            os/signal/signal_unix.go:23 +0x19 
    created by os/signal.Notify.func1.1 
            os/signal/signal.go:151 +0x2a 
    goroutine 9 [chan receive]: 
            src.elv.sh/pkg/shell/shell.go:138 +0x85 
    created by src.elv.sh/pkg/shell.initSignal 
            src.elv.sh/pkg/shell/shell.go:137 +0x91 
    goroutine 11 [chan receive]: 
            src.elv.sh/pkg/cli/prompt/prompt.go:77 +0xb6 
    created by src.elv.sh/pkg/cli/prompt.New 
            src.elv.sh/pkg/cli/prompt/prompt.go:70 +0x1bc 
    goroutine 12 [chan receive]: 
            src.elv.sh/pkg/cli/prompt/prompt.go:77 +0xb6 
    created by src.elv.sh/pkg/cli/prompt.New 
            src.elv.sh/pkg/cli/prompt/prompt.go:70 +0x1bc 
    runtime error: index out of range [0] with length 0 
    Execing recovery shell /bin/sh 
    opened by rsteube 2
  • v0.18.0(Apr 11, 2022)

  • v0.8(Sep 23, 2018)

    This is another pre-release, for no particular reason other than lack of pre-releases for a long time.

    As always, binaries are on https://dl.elvish.io.

    Breaking changes

    • The unpack builtin is now known as explode, for more excitement.

    • Mode-specific editor commands now reside in mode-specific subnamespaces of le: (they used to be all directly under le:). For instance, navigation-related builtins are now to be found in le:nav:. For example, le:nav-left has become le:nav:left.

      Names of most builtins undergo a simple mechanical transformation like in the example. Notable exceptions are:

      • le:start-xxx builtins that are now le:xxx:start.

      • le:navigation-default is now le:nav:default, in consistency with other navigation-mode commands.

      • Commands like le:move-dot-left are still in the le: namespace; they are not considered to be insert-mode-specific.

    Notable fixes and enhancements

    • Test coverage has increased to almost 50%.

    • The edit package has seen some cleanups and refactors.

    • It is now possible to pin and hide directories in location mode, using $le:loc-pinned and $le:loc-hidden respectively (#326 #342).

    • Matching in location mode is now more sensible (#338).

    • Special builtins and and or have been added, with similar semantics as Python.

      ~> and $true $false
      ▶ $false
      ~> and $false ?(echo 233)
      ▶ $false
      ~> and $true 1
      ▶ 1
    • A not builtin has been added that negates boolean values.

    • Pressing Ctrl-V will now put Elvish into "raw mode" that causes the next key press to be read literally, like in other shells (#182). However, the implementation is now buggy (#350).

    • An embedded:readline-binding module has been added. Add use embedded:readline-binding to get a (partial) readline-esque binding (#339).

    • An experimental -match builtin for regular expression matching was added.

    • A repr builtin for printing the representation of objects has been added.

    • Elvish per-se no longer depends on cgo for compiling (#345). However, Elvish still uses sqlite, which requires cgo to compile.

    • When completing a variable in a namespace, e.g. put $le:lo<Tab>, the candidate menu now only shows the variable names (like loc-pinned) instead of the whole qualified name (like $le:loc-pinned). Under the hood, the definition of what is being matched against candidates, as well as the candidates themselves, have changed. When using the default prefix matcher, this has only consequence on how candidates are displayed. However, for other matchers this will make a difference.

    • An experimental variable $le:-use-subseq-matcher has been introduced. If it is set to $true, Elvish matches completion candidates using a subsequence matching algorithm. Using the example in the previous bullet, in put $le:lo<Tab>, lo is used to match against loc-pinned instead of the entire $le:lo, because loc-pinned instead of $le:loc-pinned is now considered the candidate.

    Source code(tar.gz)
    Source code(zip)
  • v0.7(Sep 23, 2018)

    As always, binaries are on dl.elvish.io.

    Breaking changes

    Almost all the breaking changes are about control structures. If you have scripts written for 0.6 or earlier, you can use fix-for-0.7 to upgrade your scripts automatically.

    1. Control structures used to mimic POSIX shell, but now use curly braces in a Go-like style:

      if (eq a a) {
          echo foo
      } else {
          echo bar

      Note that in the above code, the opening brace { must:

      1. Appear on the same line with if. Otherwise it will be considered to be another command, and elvish will complain that if does not have enough arguments.

      2. Have a space before it. Otherwise it will be parsed as brace expansion (as in echo {a,b}{c,d}) instead.

      The newline after { can be substituted by a space, so you can write these in one line if you must:

      if (eq a a) { echo foo } else { echo bar }
    2. There used to be a special "boolean return value" for functions like == or eq to indicate whether it has succeeded or failed, indicated by ✗ when failure happens. Now they simply output a boolean value $true or $false (#319).

      The ?(...) operator used to capture the aforementioned "boolean return value". Use the output capture operator (...) instead. The ?(...) operator has been repurposed to capture exceptions.

    3. The if and while control structures now take values instead of pipelines (also see #319). Together with 1 and 2, this code

      if == $x 1; then
          echo 1
          echo 2

      should now be written as

      if (== $x 1) {
          echo 1
      } else {
          echo 2
    4. The for control structure has been changed to operate on one iterable value, instead of a bunch of values. The in keyword is nolonger needed. For example, this code

      for x in lorem ipsum; do
          echo $x

      should now be written as

      for x [lorem ipsum] {
          echo $x
    5. The try control structure is only changed syntactically. This piece of code:

      except e
          put $e
          echo all well
          echo finally

      is now written as:

      try {
      } except e {
          put $e
      } except {
          echo all well
      } finally {
          echo finally

    Notable enhancements

    A but: glob qualifier has been introduced to exclude results from globbing. For instance, to remove all files in the current directory except parse, do:

    rm -r *[but:parse]

    The qualifier only accepts literal file names for now.

    Source code(tar.gz)
    Source code(zip)
  • v0.6(Sep 23, 2018)

    As always, binaries are found on dl.elvish.io.

    Breaking changes

    • The use builtin now looks for modules under ~/.elvish/lib instead of ~/.elvish.
    • In navigation mode (^N) and history listing mode (^R), Enter now inserts the selected item and exit the mode. To insert without exiting, use Alt-Enter (#306).

    Notable enhancements

    (Experimental features will change before 1.0. All other features might change before 1.0.)

    • An experimental -ifaddr builtin outputs the IP addresses of this host, along with the network prefix length.
    • Two new builtins, {has,search}-external have been added. The former is a predicate and the latter outputs the searching result and errors when the external cannot be found.
    • The le:styled builtin now accepts textual styles like green and bg-red (#301). For instance, this writes haha with green font and red background: echo (le:styled haha 'green;bg-red').
    • History listing can be filtered case-insensitively by pressing ^G.
    • Exception backtrack has been improved. When multiple commands in a pipeline throw exceptions, the backtrack is shown as a tree. Try fn f { fail f }; f | f.
    • Character sets, ranges and classes are now supported in wildcards (#298).
    • A new spacey syntax for assignments has been introduced (#294).
    • Tab-completion now works for redirs (try ls > and Tab) and some indices (try echo $le:bindg[ and Tab).
    Source code(tar.gz)
    Source code(zip)
  • v0.5(Sep 23, 2018)

    Breaking changes

    • The println builtin is now known as echo, shadowing the external echo.
    • Changes on comparison builtins:
      • A family of string comparison builtins have been added, <s, <=s, ==s, !=s, >s and >=s (#238).
      • The is builtin is the new generic (shallow) equality predicate. The deep equality predicate deepeq is now known simply as eq.
      • The == builtin now compares numbers -- == 1 1.0 is true, while == a a throws an exception. To compare strings, use either ==s or is.
    • Automatic use'ing has been removed. All modules must be used before use.
    • The into-lines builtin is now known as to-lines.
    • The history builtin has been removed; use $le:history instead (#267).

    Other notable changes

    • When run interactively, predicates that return false are now indicated with a ✗ sign.
    • Completion listing now has black text over a light background (#184), and is no longer unnecessarily tall (https://asciinema.org/a/87937).
    • Strings can now be indexed to obtain substrings (#243).
    • The peach command, a parallel version of each has been added (#244).
    • Multi-level modules are supported. For instance, the a:b module is the file ~/.elvish/a/b.elv (#249).
    • When exceptions are thrown, a full stack trace is now displayed (#207, https://asciinema.org/a/88801).
    • An unstable builtin -time has been added that shows the time to run a function.
    • An unstable builtin -override-wcwidth has been added to override wcwidth.
    • The navigation mode now supports previewing UTF-8-encoded text files (https://asciinema.org/a/89374).
    • A variable $le:after-readline has been added. It is a list of functions to be called just after the line editor completes reading input, with the input as the sole argument.
    • The auxiliary elvish-stub program has been removed, and elvish now always runs in foreground. As a nice side effect, elvish is go-gettable again.
    Source code(tar.gz)
    Source code(zip)
A compiler for the ReCT programming language written in Golang

ReCT-Go-Compiler A compiler for the ReCT programming language written in Golang

null 6 Apr 7, 2022
Starlark in Go: the Starlark configuration language, implemented in Go

Starlark in Go This is the home of the Starlark in Go project. Starlark in Go is an interpreter for Starlark, implemented in Go. Starlark was formerly

Google 1.6k May 10, 2022
A fast script language for Go

The Tengo Language Tengo is a small, dynamic, fast, secure script language for Go. Tengo is fast and secure because it's compiled/executed as bytecode

daniel 2.7k May 9, 2022
Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. https://vlang.io

The V Programming Language vlang.io | Docs | Changelog | Speed | Contributing & compiler design Key Features of V Simplicity: the language can be lear

The V Programming Language 29k May 18, 2022
Compiler for a small language into x86-64 Assembly

Compiler This project is a small compiler, that compiles my own little language into X86-64 Assembly. It then uses yasm and ld to assemble and link in

Maurice Tollmien 236 Apr 16, 2022
Oak is an expressive, dynamically typed programming language

Oak ?? Oak is an expressive, dynamically typed programming language. It takes the best parts of my experience with Ink, and adds what I missed and rem

Linus Lee 152 May 7, 2022
Sand is the next, versatile, high-level compiled or interpreted language that's easy to learn and performant to run.

Sand is the newest, dynamically typed, interpreted programming language. Table of Contents History Project Stats History Sand was created as part of @

Neuron AI 4 Mar 13, 2022
A versatile library for building CLI applications in Go

mow.cli Package cli provides a framework to build command line applications in Go with most of the burden of arguments parsing and validation placed o

Jawher Moussa 797 Apr 29, 2022
Powerful and versatile MIME sniffing package using pre-compiled glob patterns, magic number signatures, XML document namespaces, and tree magic for mounted volumes, generated from the XDG shared-mime-info database.

mimemagic Powerful and versatile MIME sniffing package using pre-compiled glob patterns, magic number signatures, xml document namespaces, and tree ma

Ronen Ulanovsky 74 Mar 5, 2022
Versatile Go code generator.

Generis Versatile Go code generator. Description Generis is a lightweight code preprocessor adding the following features to the Go language : Generic

SenseLogic 33 May 13, 2022
Sabakan is a versatile network boot server designed for large on-premise data centers.

Sabakan is a versatile network boot server designed for large on-premise data centers. Currently, it is made only for Flatcar Container Linux.

Cybozu Go 97 May 1, 2022
Floppa programming language inspired by the brainf*ck programming language. Created just for fun and you can convert your brainf*ck code to floppa code.

Floppa Programming Language Created just for fun. But if you want to contribute, why not? Floppa p.l. inspired by the brainf*ck programming language.

null 18 Apr 26, 2022
T# Programming Language. Something like Porth, Forth but written in Go. Stack-oriented programming language.


T# 89 May 9, 2022
Yayx programming language is begginer friendly programming language.

Yayx Yayx programming language is begginer friendly programming language. What have yayx: Easy syntax Dynamic types Can be compiled to outhers program

null 1 Dec 27, 2021
Yayx programming language is begginer friendly programming language.

Yayx Yayx programming language is begginer friendly programming language. What have yayx: Easy syntax Dynamic types Can be compiled to outhers program

Yayx Programming Language 6 Jan 1, 2022
Automatically spawn a reverse shell fully interactive for Linux or Windows victim

Girsh (Golang Interactive Reverse SHell) Who didn't get bored of manually typing the few lines to upgrade a reverse shell to a full interactive revers

null 254 May 14, 2022
Generate an interactive, autocompleting shell for any Cobra CLI

cobra-shell Description Leverages the Cobra completion API to generate an interactive shell for any Cobra CLI, powered by go-prompt. On-the-fly autoco

Brian Strauch 25 Apr 23, 2022
An interactive shell for go application

goshell An interactive shell for go application in normal mode ctrl-c break exec

null 0 Dec 24, 2021
A simple CLI based rock-paper-scissors game created in GO with interactive shell prompt.

rock-paper-scissors A simple CLI (Command Line Interface) based rock-paper-scissors game with interactive shell prompt. Language Download Grab a binar

Saif Shahriar 0 Feb 1, 2022
Expressive end-to-end HTTP API testing made easy in Go

baloo Expressive and versatile end-to-end HTTP API testing made easy in Go (golang), built on top of gentleman HTTP client toolkit. Take a look to the

Tom 725 May 12, 2022
Simple and expressive toolbox written in Go

ugo Simple and expressive toolbox written with love and care in Go. Deeply inspired by underscore.js and has the same syntax and behaviour Fully cover

Alexey Derbyshev 26 Nov 22, 2021
expressive DynamoDB library for Go

dynamo is an expressive DynamoDB client for Go, with an easy but powerful API. dynamo integrates with the official AWS SDK.

Greg 973 May 8, 2022
Expressive flags for Go

Expressive flags for Go Package xflags provides an alternative to Go's flag package for defining and parsing command line arguments with an emphasis o

The Cavalier Gopher 17 Mar 15, 2022
A simple and expressive HTTP server mocking library for end-to-end tests in Go.

mockhttp A simple and expressive HTTP server mocking library for end-to-end tests in Go. Installation go get -d github.com/americanas-go/mockhttp Exa

Americanas Go 6 Dec 19, 2021
BuildKit - A toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner

BuildKit BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Key features: Automati

CrazyMax 5 Feb 19, 2022
painless task queue manager for shell commands with an intuitive cli interface (execute shell commands in distributed cloud-native queue manager).

EXEQ DOCS STILL IN PROGRESS. Execute shell commands in queues via cli or http interface. Features Simple intuitive tiny cli app. Modular queue backend

Mohammed Al Ashaal 12 Jan 29, 2022
ap 是一个 shell 工具,可以让其它 shell 命令的输出能够自动进入交互翻页模式

ap -- auto-pager ap 是一个 shell 工具,可以让其它 shell 命令的输出能够自动进入交互翻页模式。 ap 由两部分组成,一个 Go 语言编写的二进制程序,负责捕获命令的输出并支持翻页, 和一组 shell 脚本,负责为用户指定的命令清单创建与之同名的 wrapper。 经

flw 12 Apr 12, 2022
Assume-shell - A tool to create a shell with AWS environment credentials set

assume-shell This tool will request AWS credentials for a given profile/role and

Erik Jansson 2 Feb 14, 2022
Advent of Code is an Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved in any programming language you like.

Advent of Code 2021 Advent of Code is an Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved

Kemal Ogun Isik 0 Dec 2, 2021