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.

Comments
  • 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...)

  • 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/).

  • 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.

  • `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.

  • 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.

  • 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++ {
    	f(i)
    }
    

    While in Elvish that would be written thusly:

    for i [(range 10)] {
        f(i)
    }
    

    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|
        f(i)
    }
    
  • 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).

  • 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.

  • 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).

  • 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?

  • Support arbitrary-precision numbers

    Support arbitrary-precision numbers

    Upsides:

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

    Downsides:

    • 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)?
  • exploding breaks on @varname vars

    exploding breaks on @varname vars

    note the comments

    ~> echo $version
    0.18.0
    ~> 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'
    

    regards

  • 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
    FAIL    src.elv.sh/pkg/edit     14.283s
    

    And:

    --- 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
    FAIL    src.elv.sh/pkg/edit     19.600s
    

    And:

    --- 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
    FAIL    src.elv.sh/pkg/edit     8.534s
    
  • 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

  • crash: unexpected rune '`'

    crash: unexpected rune '`'

    affected version

    0.18.0

    summary

    Crash on completion related #1511

    steps to reproduce

    echo `<TAB>
    

    log

    goroutine 1 [running]:ty]: unexpected rune '`' 
    src.elv.sh/pkg/sys.DumpStack() 
            src.elv.sh/pkg/sys/dumpstack.go:10 +0x66 
    src.elv.sh/pkg/shell.handlePanic() 
            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.initCompletion.func4() 
            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).Run(0xc000216640) 
            src.elv.sh/pkg/cli/loop.go:129 +0x1ac 
    src.elv.sh/pkg/cli.(*app).ReadCode(0xc00021c000) 
            src.elv.sh/pkg/cli/app.go:475 +0x49a 
    src.elv.sh/pkg/edit.(*Editor).ReadCode(0xc000010010?) 
            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.composite.Run(...) 
            src.elv.sh/pkg/prog/prog.go:118 
    src.elv.sh/pkg/prog.Run({0xc000010010, 0xc000010018, 0xc000010020}, {0xc000020200, 0x1, 0x1}, {0x5603fb5967e8, 0xc00000e6c0}) 
            src.elv.sh/pkg/prog/prog.go:83 +0x3d4 
    main.main() 
            src.elv.sh/cmd/withpprof/elvish/main.go:17 +0x1c5 
    goroutine 6 [chan receive]: 
    src.elv.sh/pkg/eval.getBlackholeChan.func1() 
            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]: 
    os/signal.signal_recv() 
            runtime/sigqueue.go:151 +0x2f 
    os/signal.loop() 
            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.initSignal.func1() 
            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).loop(0xc00021a460) 
            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).loop(0xc00021a540) 
            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 
    sh-5.1$ 
    
    
A compiler for the ReCT programming language written in Golang

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

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

May 10, 2022
A fast script language for Go
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

May 9, 2022
Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. https://vlang.io
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

May 8, 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

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

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 @

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

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

Mar 5, 2022
Versatile Go code generator.
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

Apr 23, 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.

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

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.

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

The T# Programming Language WARNING! THIS LANGUAGE IS A WORK IN PROGRESS! ANYTHING CAN CHANGE AT ANY MOMENT WITHOUT ANY NOTICE! Something like Forth a

May 9, 2022
Yayx programming language is begginer friendly programming language.
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

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

Jan 1, 2022
Automatically spawn a reverse shell fully interactive for Linux or Windows victim
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

Apr 21, 2022
Generate an interactive, autocompleting shell for any Cobra CLI
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

Apr 23, 2022
An interactive shell for go application

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

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

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

May 12, 2022