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

As rasied on the user group, I asked about the possibility of having the documentation for each command available via the command line, so we could type e.g. > help randint and get the documentation that is already present in the go source code, e.g. https://github.com/elves/elvish/blob/master/pkg/eval/builtin_fn_num.go#L576

Currently this documentation is in markdown. The simplest solution would be to convert from markdown to plain text, resulting in something like (for this I used pandoc -t plain):

elvdoc:fn randint

    randint $low $high

Output a pseudo-random integer in the half-open interval [$low, $high).
Example:

    ~> # Emulate dice
    randint 1 7

This would already be a big advance. Of course for cherries on top it would be nice if links could be preserved and code could get syntax highlighting. I do not know anything about go and how feasible this would be, I assume there are many markdown packages available...

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?

It's api to and update codebuffer with current entry in histwalk mode.

Resolves #1636

With this new api, I was able to switch to command-mode directly from histwalk mode.

set edit:history:binding["Ctrl-["] =  { edit:history:accept; edit:close-mode; edit:command:start }

I'm not familiar with elvish code base. Please let me know it this api itself and it's implementation is correct. I couldn't find a way to get codebuffer in the test case. Wish to get some help.

Elvish used to allow the foo=bar cmd syntax similar to other shells. This has changed and as it is a common motif I thought it would be good to mention it in the elvish<->bash comparison table (at least me as a generic end-user often goes there to work out how to do things). I added both the { tmp ... } option and also using env command as a shortcut, although I know this is not strictly "elvish" syntax...

I also thought that as environment variable are often important for many shell tasks, expanding the Setting variables section to detail the use of builtins like set-env or the E: namespace will help new users orient themselves.

I wanted to close history navigation and start command(vi) mode to edit command in the history.

Up -> ESC

But it clears the line. So I tried this but it doesn't work properly.

set edit:history:binding["Ctrl-["] =  { edit:command:start }

And this doesn't work as edit:close-mode clears the line.

set edit:history:binding["Ctrl-["] =  { edit:close-mode; edit:command:start }

I am searching for some api to preserve current line in history mode. Or let me know if anyone knows the trick. I'm not sure some new api should be introduced for this.

There was a recent discussion on the IM channels about how to deal with the exception raised by builtins like break, continue, and return. That caused me to notice that this fails to produce the expected, true, result:

elvish> var e = ?(break)
elvish> eq ?(break) $e
▶ $false

That is, obviously, a contrived and not particularly interesting example in isolation. But it illustrates that the eq command fails to correctly compare exception objects such as raised by the control flow builtins. Which makes it impossible for examples like this (again, contrived and simplified) to work as expected:

elvish> try { break } catch e { if (eq ?(break) $e) { put "break captured" } }

Currently those values in the function pseudo-map contain lists in the order exactly as defined - in contrast to make-map, for example, which seems to order its keys alphabetically:

~> put [c 3] [a 1] [b 2] | make-map
▶ [&a=1 &b=2 &c=3]
~> put {|&c=3 &a=1 &b=2|}[opt-names]
▶ [c a b]

I feel that this should be clarified in the documentation. Map is defined as "a value containing unordered key-value pairs", so the first result is to be (not) expected. But since the "mapping" of option values and names is supplied in the pseudo-map as two lists, it feels like it should match the definition order. Either way, clarification would be much appreciated.

For context, my current use-case are with-statements (as in Python). One example:

 fn with-temp-dir { |&parent='' f|
    use path
    use util

    var @args = (each { |name|
        path:temp-dir &dir=$parent $name'-*'
    } $f[arg-names])
    var @opt_values = (each { |name|
        path:temp-dir &dir=$parent $name'-*'
    } $f[opt-defaults])

    defer {
        { all $args; all $opt_values } | each { |dir|
            rm -rf $dir
        }
    }

    var opts = (util:zip $f[opt-names] $opt_values | make-map)
    call $f $args $opts
}

~> with-temp-dir {|cyan magenta| put $cyan $magenta}
▶ /tmp/cyan-3550046558
▶ /tmp/magenta-93444558
~> with-temp-dir {|yellow &dark=black| put $yellow $dark}
▶ /tmp/yellow-3399318214
▶ /tmp/black-2816232334

(by the way, any critique/suggestions regarding this are much appreciated, but having possibility of defining things like this feels really nice)

I'm sorry for ruining 256 open issues for something this trivial. :-)

To set the stage, for a variable v, the meaning of $@v and set @v = value … is clear:

⬥ var @v = a b c
⬥ put $@v
⮕ a
⮕ b
⮕ c

Note that $@v returns what we gave to set @v.

But involve some array references, and things are not as clear:

⬥ var @v = [a b c] [d e f] [g h i]
⬥ set @v[1] = x y z
⬥ put $v     # produces expected result:
⮕ [[a b c] [x y z] [g h i]]
⬥ put $@v[1] # surprise (to me at least):
⮕ b
⮕ y
⮕ h

This breaks two reasonable expectations, IMO:

• Expanding $⟨something⟩ should reflect the RHS of a previous set ⟨something⟩ = …
• The construct $@⟨something⟩ acts like syntactic sugar for (all $⟨something⟩)

Of course, this depends on what you see as the ⟨something⟩ in a compound expression. What is most jarring is the lack of symmetry between the assignment and the expansion.

So this is my suggestion:

Change the meaning of $@variable[⟨index-expression⟩]… to evaluate the whole expression without the @, then explode the result(s).

Of course this is breaking change, so it needs to considered carefully. But I doubt there is much code out there that relies on the current behaviour.

• After such a change, replacing any $@variable[⟨index-expression⟩]… by {$@variable}[⟨index-expression⟩]… will result in the old behaviour. This should be fairly easy to automate. Also, since the result of such an expression is a bit tricky to figure out, I think the extra curly braces will help to make clear that something funny is going on.