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

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

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.

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.

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.

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)
}

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

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.

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

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?

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

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

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

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

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$