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
  • Interactive prompt doesn't support surrogate pairs on Windows

    Interactive prompt doesn't support surrogate pairs on Windows

    I can enter a two byte character, for example:

    Ç (U+00C7)

    Using any of these paste or input methods:

    • right click
    • Ctrl + V
    • Alt + 128

    However a three byte character:

    ∞ (U+221E) (Alt + 236)

    fails with those same methods.

    opened by 89z 22
  • 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
  • Specially named function parameters should be restricted

    Specially named function parameters should be restricted

    You can't assign a non-function to a variable whose name ends in a tilde, and you can't assign a non-namespace to a variable whose name ends in a colon. This restriction should probably apply to function arguments too, for consistency – but it does not:

    ⬥ fn f {|fun~ ns:| put $fun~[body] $ns:[body] }
    ⬥ f [&body=hi] [&body=ho]
    ⮕ hi
    ⮕ ho
    opened by hanche 0
  • Add a `runtime:db-path` var

    Add a `runtime:db-path` var

    A recent problem by a user illustrated the need for a way to determine the path to the interactive database file without the user having to manually apply the rules for determining the path. A $runtime:db-path var would make it unambiguous what file Elvish is using.

    opened by krader1961 0
  • epm packages depending on external commands

    epm packages depending on external commands

    As a shell, Elvish encourages taking advantage of external commands. As such, EPM packages may depend on external commands. Such dependencies currently have to be documented by the package authors, and the users will have to remember installing them. The EPM system could provide some help to reduce the friction.

    There are roughly 3 different scenarios when a package depends on external commands:

    1. The package depends on external commands typically provided by a UNIX system, e.g. cat and grep. The same command can have different flags and different behaviors across UNIX flavors, and are often non-existent on Windows.

      Elvish should help package authors handle the platform differences. One possible approach is to provide a builtin module exposing a "least common denominator" version of these commands. The package authors will need to remember to use that module instead of using the commands directly though. Maybe this is a valid use case to support "import from" found in other languages like Python and JavaScript.

    2. The package depends on external commands that are not part of UNIX systems, but popular enough to be packaged by multiple system-level package managers, e.g. ffmpeg, gm and pandoc. EPM can help by letting the package author specify the following:

      • How to install the dependencies with different package managers
      • The required version range

      Automatically running the installation instructions and checking the version can be very useful.

    3. The package either depends on external commands that are not popular enough to be packaged by package managers, or depends on a version that is too new to be packaged. In this case, the command will have to be built. EPM can help in two ways:

      • Accept building instructions and build the dependencies on the user's computer, or
      • Accept pre-built binaries provided by the package author

      This is in fact somewhat analogous to (2) and may overlap with it.

      A key concern here is that the external command (whether built on user's computer or pre-built) may be placed somewhere specific to the EPM package (and outside the default PATH) since it's less likely to be generally useful to the user's system.

    These are just some preliminary thoughts. I might split these into separate issues if the implementation for different pieces turn out to be disjoint enough.

    opened by xiaq 3
  • The `-cpuprofile` flag no longer works

    The `-cpuprofile` flag no longer works

    I was working on a fix for issue #1377 and was surprised that

    1. the default elvish binary did not support the -cpuprofile flag, and

    2. that building with go build -o ./elvish ./cmd/withpprof/elvish did not result in an Elvish binary that correctly handled the -cpuprofile flag. With, or without, my fix for handling the exit command.

    The reason for both issues is commit 33a04f8dc, merged seven months ago, that refactored the code in response to the desire to minimize the size of the elvish binary for unusual situations. Such as using elvish as a shell in an embedded environment where every byte in the size of the binary matters.

    Issue #1 is because we now have to do something like go build ./cmd/withpprof/elvish rather than simply running make get (which, FWIW, I have never liked as a make target name).

    Issue #2 is because the defer in the cpuprofile setup stops profiling when the pprof Run() function returns. Which is before anything useful to be profiled is executed.

    On my macOS ARM system the elvish binary without pprof support is 9.5 MB, and with it the size is 9.8 MB. That is a 3.2% increase in size for profiling support. Performance metrics are extremely useful; especially in a relatively new shell like Elvish that is undergoing rapid development. A borderline insignificant increase in the size of the binary is worthwhile, IMHO, to make it easy to capture performance metrics that will help us figure out where it is most advantageous to make performance improvements.

    opened by krader1961 4
  • how should glob type modifiers behave with respect to symlinks

    how should glob type modifiers behave with respect to symlinks

    My fix for issue #1240 (broken symlink handling short-circuits glob expansion) had the unexpected, at least by me, side-effect of changing the behavior of examples like this:

    > mkdir d
    > ln -s d s
    > echo *[type:dir]

    Prior to my fix (PR #1567) that would output both d and s. My fix causes it to only output d. See this comment thread for more context. I believe it should output both d and s while @xiaq believes, at least as I write this, that the symlink above should be treated as a regular file. This is their comment from the 0.19.0-release-notes.md file:

    -   Symbolic links are now always treated as ordinary files by the global
        modifiers `type:dir` and `type:regular` in wildcard expansions.

    However, that isn't actually the behavior. If that was the behavior then this would output both file1 and file2:

    > touch file1
    > ln -s /invalid/path file2
    > echo *[type:regular]

    The symlink is neither a regular file or directory regardless of the filesystem object it points to.

    Even worse is that globs expanded without a modifier do not match symlinks (these symlinks are from prior experiments in my ~/tmp directory):

    > ls -lhtr
    lrwxr-x--- 1 krader staff 13 Aug 30 20:19 file2 -> /invalid/path
    lrwxr-x--- 1 krader staff  5 Aug 30 20:20 file3 -> file1
    lrwxr-x--- 1 krader staff  1 Aug 30 20:31 s -> d
    > rm *
    Exception: wildcard has no match
    [tty 94], line 1: rm *

    This was broken before my "fix" because broken symlinks short-circuited glob expansion. Which means the new behavior is equivalent to the old behavior. However, I would argue that absent a glob modifier those symlinks should be included in the files matching the glob.

    opened by krader1961 0
  • suggested enhancement to the `flag` module to reduce boilerplate code

    suggested enhancement to the `flag` module to reduce boilerplate code

    I originally asked this on the discussion channels and decided it warranted an issue given the reply by @xiaq.

    I used the flag:parse-getopt function for the first time to implement a which function. I did this because the Windows MSYS2 which command produces output inconsistent with Elvish (e.g., /usr/bin/ls rather than c:\msys64\usr\bin\ls.exe) which is slightly confusing. Using flag:parse-getopt wasn't particularly hard but required more code than I expected. I was hoping for something more like the Fish argparse command. Obviously not in every detail but with regard to directly setting variables in the current context according to the parsed options. So that the latter half of this snippet could be omitted:

    fn which {|@args|
        var all = $false
        var search = $false
        var arg-specs = [
          [&short=a &arg-optional=$false &arg-required=$false]
          [&short=s &arg-optional=$false &arg-required=$false]
        var flags args = (
            flag:parse-getopt $args $arg-specs ^
                &stop-after-double-dash=$true &stop-before-non-flag=$true &long-only=$false
        for flag $flags {
            if (eq $flag[spec][short] a) {
                set all = $true
            if (eq $flag[spec][short] s) {
                set search = $true

    @xiaq proposed adding a callback for each option that is run when the option has been successfully parsed. @xiaq also stated that "Setting local variables like fish is not feasible in Elvish it would violate lexical scoping." However, I don't see why that is true if the var has already been declared as in the example above (it is true that the Fish argparse does not require declaring each var corresponding to an option before calling argparse). Nonetheless, given the design of Elvish, and existing precedent, it probably makes more sense to use a callback mechanism than magically setting a var that has already been declared. Which leads to a solution along these lines:

    fn which {|@args|
        var all = $false
        var search = $false
        var arg-specs = [
          [&short=a &arg-optional=$false &arg-required=$false
           &set={|value| set all = $value }]
          [&short=s &arg-optional=$false &arg-required=$false
           &set={|value| set search = $value }]
        var flags args = (
            flag:parse-getopt $args $arg-specs ^
                &stop-after-double-dash=$true &stop-before-non-flag=$true &long-only=$false

    That eliminates a lot of boilerplate code and is arguably clearer about the intent while still supporting the existing behavior and idioms for handling options.

    P.S., Obviously instead of &set there could be a &var option that takes the name of the variable in the current lexical scope to be set with the value of the parsed option; e.g., &var=all for the first arg-spec above. That would eliminate even more boilerplate code. It would, obviously, throw an exception if the var wasn't already declared in the current scope. In fact, that should be detectable as a compilation error since I can't see a good reason to support dynamic var names (e.g., &var=$var-name). The var name should have to be a bare word.

    opened by krader1961 1
  • 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 8 Nov 17, 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.8k Nov 17, 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 3k Nov 28, 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 30.9k Nov 23, 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 241 Nov 3, 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 187 Nov 22, 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 836 Nov 21, 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 83 Nov 3, 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 38 Oct 9, 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 105 Nov 13, 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 19 Oct 20, 2022
T# Programming Language. Something like Porth, Forth but written in Go. Stack-oriented programming language.


T# 92 Jun 29, 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 7 May 20, 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 285 Nov 21, 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 29 Aug 31, 2022
An interactive shell for go application

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

null 1 Aug 4, 2022
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 Oct 9, 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