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

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.

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?

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

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.

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.

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.

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]
d

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]
file1

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.

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.