ion issueshttps://gitlab.redox-os.org/redox-os/ion/-/issues2018-06-12T14:22:02Zhttps://gitlab.redox-os.org/redox-os/ion/-/issues/621Replace app_dirs crate with xdg crate2018-06-12T14:22:02ZMichael Aaron Murphymmstick@pm.meReplace app_dirs crate with xdg crateMay be a better choice in the long term.May be a better choice in the long term.https://gitlab.redox-os.org/redox-os/ion/-/issues/622Calling cd (a builtin) from an alias2018-06-12T14:22:02ZMichael Aaron Murphymmstick@pm.meCalling cd (a builtin) from an alias*Created by: anxiousmodernman*
In zsh I often create this alias to **u** to jump to my parent directory:
```zsh
alias u="cd .."
```
I've tried a few variants in ion, but I can't get it to work. My guess is that alias executes a ...*Created by: anxiousmodernman*
In zsh I often create this alias to **u** to jump to my parent directory:
```zsh
alias u="cd .."
```
I've tried a few variants in ion, but I can't get it to work. My guess is that alias executes a subprocess that has state independent of the parent process (the current shell).
#409 has `exec` on the TODO list. Is exec the blocker to doing something like this in ion? A related design question might be: after exec is implemented, should all aliases be `exec`'d? E.g., aliases would be more like a macro that replaces characters and can modify the running shell's state.
https://gitlab.redox-os.org/redox-os/ion/-/issues/569Perform Builtin Lookup When Parsing2018-06-12T14:22:02ZMichael Aaron Murphymmstick@pm.mePerform Builtin Lookup When ParsingJobs should make note if they are a builtin or not during parsing, rather than execution. This would lead to some possibly-big improvements for loops. With the static builtin map, functions will always have the same index position, so th...Jobs should make note if they are a builtin or not during parsing, rather than execution. This would lead to some possibly-big improvements for loops. With the static builtin map, functions will always have the same index position, so the `Job` structure could be extended to contain a static reference to it's builtin function.https://gitlab.redox-os.org/redox-os/ion/-/issues/619and/or followed by let results in command not found2018-06-12T14:22:02ZDan Robertsonand/or followed by let results in command not found**Reproduction**:
```
echo "This does not have a bad exit status"; and let x = "something"
```
**Expected behavior**:
`x` is set to `something`
**Actual behavior**:
```
ion: command not found: let
```
**Build informatio...**Reproduction**:
```
echo "This does not have a bad exit status"; and let x = "something"
```
**Expected behavior**:
`x` is set to `something`
**Actual behavior**:
```
ion: command not found: let
```
**Build information**:
A `git bisect` showed that this started at 7d9584ee254b6019343d034a4de07e2b5c3e19bd
https://gitlab.redox-os.org/redox-os/ion/-/issues/658array_methods example run failed2018-06-12T14:22:02ZMichael Aaron Murphymmstick@pm.mearray_methods example run failed*Created by: Matrix-Zhang*
the output is:
```
one one
one twoone
o n e t w o
111 110 101 116 119 111
o n e t w o
ion: lines: invalid array method
ion: reverse: invalid array method
ion: reverse: invalid array method
ion:...*Created by: Matrix-Zhang*
the output is:
```
one one
one twoone
o n e t w o
111 110 101 116 119 111
o n e t w o
ion: lines: invalid array method
ion: reverse: invalid array method
ion: reverse: invalid array method
ion: reverse: invalid array method
```
my ion's version is:
```
ion 1.0.5 (x86_64-unknown-linux-gnu)
rev e81543bfc389136a355815d3e47e5266adb405b8
```
https://gitlab.redox-os.org/redox-os/ion/-/issues/664Globbing Should Occur After Brace Expansion2018-06-11T19:16:24ZMichael Aaron Murphymmstick@pm.meGlobbing Should Occur After Brace ExpansionThe following should be a valid pattern:
```ion
echo {a,b,c}*
```
Which internally would expand to:
```ion
echo [a* b* c*]
```
and then globbing would be applied at this pointThe following should be a valid pattern:
```ion
echo {a,b,c}*
```
Which internally would expand to:
```ion
echo [a* b* c*]
```
and then globbing would be applied at this pointstratactstratact1@gmail.comstratactstratact1@gmail.comhttps://gitlab.redox-os.org/redox-os/ion/-/issues/328Functions and Variable Scopes2018-06-11T15:22:17ZMichael Aaron Murphymmstick@pm.meFunctions and Variable ScopesOne area that we need to discuss is how we want to handle variable scopes, if at all.
- Should functions have access to the global scope, or should they create and manage their own scope?
- Should values created in a function be drop...One area that we need to discuss is how we want to handle variable scopes, if at all.
- Should functions have access to the global scope, or should they create and manage their own scope?
- Should values created in a function be dropped when the function exits?
https://gitlab.redox-os.org/redox-os/ion/-/issues/728Arguments passed incorrectly to recursively called functions2018-06-11T15:22:16ZMichael Aaron Murphymmstick@pm.meArguments passed incorrectly to recursively called functions*Created by: xTibor*
**Reproduction**:
```
fn recursive a b c d
echo $a $b $c $d
sleep 1
recursive $d $a $b $c
end
recursive 1 2 3 4
```
**Expected behavior**:
```
1 2 3 4
4 1 2 3
3 4 1 2
2 3 4 1
1 2 3 4
...*Created by: xTibor*
**Reproduction**:
```
fn recursive a b c d
echo $a $b $c $d
sleep 1
recursive $d $a $b $c
end
recursive 1 2 3 4
```
**Expected behavior**:
```
1 2 3 4
4 1 2 3
3 4 1 2
2 3 4 1
1 2 3 4
...
```
**Actual behavior**:
```
1 2 3 4
4 4 4 4
4 4 4 4
4 4 4 4
4 4 4 4
...
```
**Build information**:
`rustc -V`: `rustc 1.28.0-nightly (952f344cd 2018-05-18)`
`git rev-parse HEAD`: 017d807566560684cec6d2ee79dd8775ed5a24b0
System: KDE neon 5.12 (Ubuntu 16.04)
jD91mZM2jD91mZM2https://gitlab.redox-os.org/redox-os/ion/-/issues/487Review Exit Status Codes2018-06-10T04:02:25ZMichael Aaron Murphymmstick@pm.meReview Exit Status CodesWe should define a set of exit status that the shell may return. If we follow Bash, we might have something like this:
- 0 means `SUCCESS`
- 1 means `FAILURE`
- 2 means `BAD_ARG`
- 3...125 can be defined by programs executed by the...We should define a set of exit status that the shell may return. If we follow Bash, we might have something like this:
- 0 means `SUCCESS`
- 1 means `FAILURE`
- 2 means `BAD_ARG`
- 3...125 can be defined by programs executed by the shell
- 126 means `COULD_NOT_EXEC`
- 127 means `COMMAND_NOT_FOUND`
- 128 `INVALID_EXIT_ARG`
- 128+N where N is equal to the signal that stopped the shell
- 255+ is `EXIT_OUT_OF_RANGE`
But we may want to think about defining our own error codes.
https://gitlab.redox-os.org/redox-os/ion/-/issues/660History leaks between ion sessions2018-06-10T02:59:05ZMichael Aaron Murphymmstick@pm.meHistory leaks between ion sessions*Created by: ijt*
**Reproduction**: [describe how you are able to reproduce ("trigger") this bug/issue.]
Type something in one ion shell for example "echo blerg"
Open another ion session.
Press ctrl-p to get the previous command.
...*Created by: ijt*
**Reproduction**: [describe how you are able to reproduce ("trigger") this bug/issue.]
Type something in one ion shell for example "echo blerg"
Open another ion session.
Press ctrl-p to get the previous command.
**Expected behavior**: [describe the behavior you would expect the repro to yield.]
No command should appear because there is no previous command in the new session.
**Actual behavior**: [describe the actual behavior, which is presented through the repro.].
"echo blerg" appears.
**Build information**: [output of `rustc -V`, `git rev-parse HEAD`, `qemu-i386 -version`, `uname -a`, `ion --version`, etc.]
rustc 1.22.1 (05e2e1c41 2017-11-22)
Linux issac.c.googlers.com 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux
ion 1.0.0-alpha (x86_64-unknown-linux-gnu)
rev bc49acb6b9555942ba8d568914d61389052e9b2b
**Blocking/related**: [issues or PRs blocking or being related to this issue.]
**Misc**: [optional: for other relevant information that should be known or cannot be described in the other fields.]
------
_If the above does not fit the nature of the issue feel free to modify it._
https://gitlab.redox-os.org/redox-os/ion/-/issues/690Git URLs containing @ get mangled when executing git command2018-06-10T02:59:05ZMichael Aaron Murphymmstick@pm.meGit URLs containing @ get mangled when executing git command*Created by: forbjok*
**Reproduction**:
Try to pass a SSH git url (ex. copy & paste from either github or bitbucket) to any command in ion.
**Expected behavior**:
To be able to clone git repositories by directly pasting the url int...*Created by: forbjok*
**Reproduction**:
Try to pass a SSH git url (ex. copy & paste from either github or bitbucket) to any command in ion.
**Expected behavior**:
To be able to clone git repositories by directly pasting the url into the terminal.
**Actual behavior**:
When an URL containing @ is passed as a commandline parameter to a command, it gets mangled by ion, causing "git clone" to hang forever due to the url it receives being incorrect.
The issue can be seen easily by `echo`ing the url:
![screenshot from 2018-02-03 11-27-03](https://user-images.githubusercontent.com/4687674/35766863-5a8184c2-08e0-11e8-9dc8-928f1ac0a982.png)
Manually adding single-quotes around the URL works around the issue.
**Build information**:
```
$ rustc -V
rustc 1.25.0-nightly (616b66dca 2018-02-02)
```
```
$ ion --version
ion 1.0.0-alpha (x86_64-unknown-linux-gnu)
rev b4ec0a2463e663db4e5f7a3f708e2451b1e00399
```
---
I'm guessing this is related to @ being used to specify arrays in scripts, and not necessarily a bug per se, but it's still a nuisance when trying to clone git repositories or do anything related to git URLs (which I imagine is a fairly common task) in ion and not an issue in other shells.
https://gitlab.redox-os.org/redox-os/ion/-/issues/697first pushd does not change directory2018-06-10T02:59:05ZMichael Aaron Murphymmstick@pm.mefirst pushd does not change directory*Created by: zen3ger*
**Reproduction**:
```sh
zen3ger:~/Projects/ion# pushd ~
/home/zen3ger /home/zen3ger/Projects/ion
zen3ger:~/Projects/ion# pwd
/home/zen3ger/Projects/ion
zen3ger:~/Projects/ion# pushd
/home/zen3ger/Projects/io...*Created by: zen3ger*
**Reproduction**:
```sh
zen3ger:~/Projects/ion# pushd ~
/home/zen3ger /home/zen3ger/Projects/ion
zen3ger:~/Projects/ion# pwd
/home/zen3ger/Projects/ion
zen3ger:~/Projects/ion# pushd
/home/zen3ger/Projects/ion /home/zen3ger
zen3ger:~/Projects/ion# dirs -v
0 /home/zen3ger/Projects/ion
1 /home/zen3ger
zen3ger:~/Projects/ion# pwd
/home/zen3ger/Projects/ion
zen3ger:~/Projects/ion# pushd
/home/zen3ger /home/zen3ger/Projects/ion
zen3ger:~# pwd
/home/zen3ger
zen3ger:~# pushd Documents/
Documents/ /home/zen3ger /home/zen3ger/Projects/ion
zen3ger:~# pwd
/home/zen3ger
zen3ger:~# pushd
/home/zen3ger Documents/ /home/zen3ger/Projects/ion
zen3ger:~# pushd
Documents/ /home/zen3ger /home/zen3ger/Projects/ion
zen3ger:~/Documents# pwd
/home/zen3ger/Documents
```
**Expected behavior**:
ion changes directory on first `pushd $NEW_DIR` to `$NEW_DIR`
**Actual behavior**:
After `pushd $NEW_DIR` ion stays at the same directory. When I try to flip the directory order of the 0th and 1st entry with `pushd` it takes two cycles to actually get to the `$NEW_DIR` I've intended to go to.
It seems like after `pushd $NEW_DIR` results in the correct dir stack order of:
0 - NEW_DIR
1 - OLD_DIR
but the `cd $NEW_DIR` never happens when argument is passed to `pushd`.
**Build information**:
ion 1.0.0-alpha (x86_64-unknown-linux-gnu)
rev 18b6f5eb4a9a10ca404c9fbd302ab5b216c2f45a
**Blocking/related**:
#696 https://gitlab.redox-os.org/redox-os/ion/-/issues/696pushd on current directory2018-06-10T02:59:05ZMichael Aaron Murphymmstick@pm.mepushd on current directory*Created by: zen3ger*
**Reproduction**:
```sh
zen3ger:~/Projects/ion# pushd .
. /home/zen3ger/Projects/ion
zen3ger:~/Projects/ion# cd ../
ion: failed to set current dir to : No such file or directory (os error 2)
zen3ger:~/Project...*Created by: zen3ger*
**Reproduction**:
```sh
zen3ger:~/Projects/ion# pushd .
. /home/zen3ger/Projects/ion
zen3ger:~/Projects/ion# cd ../
ion: failed to set current dir to : No such file or directory (os error 2)
zen3ger:~/Projects/ion# popd
/home/zen3ger/Projects/ion
zen3ger:~/Projects/ion# cd ../
zen3ger:~/Projects/ion# pwd
/home/zen3ger/Projects
```
**Expected behavior**:
I should be able to push `.` on the dir stack and back up a directory. After `popd` the prompt should show the current directory path.
**Actual behavior**:
ion fails to execute `cd ../` on `.` directory. After removing `.` from the dir stack with `popd` the prompt freezez and shows the directory name where `popd` got executed.
**Build information**:
ion 1.0.0-alpha (x86_64-unknown-linux-gnu)
rev 18b6f5eb4a9a10ca404c9fbd302ab5b216c2f45a
https://gitlab.redox-os.org/redox-os/ion/-/issues/699cd pushes to directory stack2018-06-10T02:59:05ZMichael Aaron Murphymmstick@pm.mecd pushes to directory stack*Created by: zen3ger*
**Reproduction**:
```sh
zen3ger:~# dirs -v
0 /home/zen3ger
zen3ger:~# cd Projects/
zen3ger:~/Projects# dirs -v
0 /home/zen3ger/Projects
1 /home/zen3ger
zen3ger:~/Projects# cd ../../../
zen3ger:/# dir...*Created by: zen3ger*
**Reproduction**:
```sh
zen3ger:~# dirs -v
0 /home/zen3ger
zen3ger:~# cd Projects/
zen3ger:~/Projects# dirs -v
0 /home/zen3ger/Projects
1 /home/zen3ger
zen3ger:~/Projects# cd ../../../
zen3ger:/# dirs -v
0 /
1 /home/zen3ger/Projects
2 /home/zen3ger
```
**Expected behavior**:
`cd` operates on the same directory stack.
**Actual behavior**:
`cd` always pushes path to a new directory stack.
**Build information**:
ion 1.0.0-alpha (x86_64-unknown-linux-gnu)
rev 18b6f5eb4a9a10ca404c9fbd302ab5b216c2f45a
https://gitlab.redox-os.org/redox-os/ion/-/issues/682Redirection of stdin results in panic on unrwrap()2018-06-10T02:59:05ZMichael Aaron Murphymmstick@pm.meRedirection of stdin results in panic on unrwrap()*Created by: OdysseusGE*
For example `echo ls | ./target/debug/ion` results in:
> thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 25, kind: Other, message: "Inappropriate ioctl for device" }', libcore...*Created by: OdysseusGE*
For example `echo ls | ./target/debug/ion` results in:
> thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 25, kind: Other, message: "Inappropriate ioctl for device" }', libcore/result.rs:916:5
The problematic unwrap is at src/lib/shell/binary/readln.rs:30.
The ultimate problem is that liner tries to use a raw input mode, but this will fail for a redirected stdin.
Since I'm not sure where this problem should be fixed, I opened a similar issue at https://github.com/MovingtoMars/liner/issues/77
See also: https://github.com/ticki/termion/issues/39https://gitlab.redox-os.org/redox-os/ion/-/issues/683Pushd doesn't work2018-06-10T02:59:05ZMichael Aaron Murphymmstick@pm.mePushd doesn't work*Created by: SeanTater*
**Reproduction**: Type `pushd SOMEWHERE`
**Expected behavior**: It should show the new directory stack and change the directory.
**Actual behavior**: It doesn't actually change the directory.
**Build inf...*Created by: SeanTater*
**Reproduction**: Type `pushd SOMEWHERE`
**Expected behavior**: It should show the new directory stack and change the directory.
**Actual behavior**: It doesn't actually change the directory.
**Build information**:
- git commit 08cf7ed1
- rustc 1.25.0-nightly (ae920dcc9 2018-01-22)
- Native mac, not qemu
- Darwin segallag-1d8b53 16.7.0 Darwin Kernel Version 16.7.0: Thu Jan 11 22:59:40 PST 2018; root:xnu-3789.73.8~1/RELEASE_X86_64 x86_64
- ion 1.0.0-alpha (x86_64-apple-darwin)
rev 08cf7ed14096459d6ed2efb962e0435159d5928c
https://gitlab.redox-os.org/redox-os/ion/-/issues/692Manual and README.md make incorrect claims about ShellShock2018-06-10T02:59:05ZMichael Aaron Murphymmstick@pm.meManual and README.md make incorrect claims about ShellShock*Created by: andychu*
> It is written entirely in Rust, which greatly increases the overall quality and security of the shell, eliminating the possibilities of a ShellShock-like vulnerability , and making development easier.
I belie...*Created by: andychu*
> It is written entirely in Rust, which greatly increases the overall quality and security of the shell, eliminating the possibilities of a ShellShock-like vulnerability , and making development easier.
I believe this statement is incorrect. As far as I can tell, the author of this line is thinking of ShellShock as a memory corruption bug like a buffer overflow. Because Rust protects against buffer overflows, then ShellShock must be impossible.
But ShellShock is not a buffer overflow. It's a string safety bug, more like a "self shell injection" or SQL injection.
You can write ShellShock in any language (Java, Python, etc.). You just look at environment variables (which are untrusted, which will come from HTTP params in CGI) and evaluate shell code in them. Memory safety doesn't prevent this.
https://en.wikipedia.org/wiki/Shellshock_(software_bug)
Do you agree? I suggest removing the lines about ShellShock from the documentation.
I'm planning to write a bunch posts about shell and security on my blog [1], so I don't want to call this out before getting your take on it.
[1] http://www.oilshell.org/blog/
https://gitlab.redox-os.org/redox-os/ion/-/issues/693panic for let array] = "zero"2018-06-10T02:59:05ZMichael Aaron Murphymmstick@pm.mepanic for let array] = "zero"*Created by: haraldh*
**Reproduction**: [describe how you are able to reproduce ("trigger") this bug/issue.]
```
$ RUST_BACKTRACE=1 cargo run
Compiling ion-shell v1.0.0-alpha (file:///home/harald/git/ion)
Finished dev [unopti...*Created by: haraldh*
**Reproduction**: [describe how you are able to reproduce ("trigger") this bug/issue.]
```
$ RUST_BACKTRACE=1 cargo run
Compiling ion-shell v1.0.0-alpha (file:///home/harald/git/ion)
Finished dev [unoptimized + debuginfo] target(s) in 3.81 secs
Running `target/debug/ion`
# let array] = "zero"
thread 'main' panicked at 'attempt to subtract with overflow', src/lib/parser/quotes.rs:105:33
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::_print
at libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
at libstd/sys_common/backtrace.rs:59
at libstd/panicking.rs:380
3: std::panicking::default_hook
at libstd/panicking.rs:396
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:576
5: std::panicking::begin_panic
at libstd/panicking.rs:537
6: std::panicking::begin_panic_fmt
at libstd/panicking.rs:521
7: rust_begin_unwind
at libstd/panicking.rs:497
8: core::panicking::panic_fmt
at libcore/panicking.rs:71
9: core::panicking::panic
at libcore/panicking.rs:51
10: ion_shell::parser::quotes::Terminator::is_terminated
at src/lib/parser/quotes.rs:105
11: ion_shell::shell::binary::terminate::terminate_quotes
at src/lib/shell/binary/terminate.rs:57
12: <ion_shell::shell::Shell as ion_shell::shell::binary::Binary>::terminate_quotes
at src/lib/shell/binary/mod.rs:79
13: <ion_shell::shell::Shell as ion_shell::shell::binary::Binary>::execute_interactive
at src/lib/shell/binary/mod.rs:147
14: ion::main
at src/main.rs:58
15: std::rt::lang_start::{{closure}}
at /checkout/src/libstd/rt.rs:74
16: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:479
17: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102
18: std::rt::lang_start_internal
at libstd/panicking.rs:458
at libstd/panic.rs:358
at libstd/rt.rs:58
19: std::rt::lang_start
at /checkout/src/libstd/rt.rs:74
20: main
21: __libc_start_main
22: _start
```
**Expected behavior**: [describe the behavior you would expect the repro to yield.]
```ion: syntax error: ion: syntax error: extra right bracket(s)```
**Actual behavior**: [describe the actual behavior, which is presented through the repro.].
```
thread 'main' panicked at 'attempt to subtract with overflow', src/lib/parser/quotes.rs:105:33
note: Run with `RUST_BACKTRACE=1` for a backtrace.
```
**Build information**: [output of `rustc -V`, `git rev-parse HEAD`, `qemu-i386 -version`, `uname -a`, `ion --version`, etc.]
```
$ rustc -V
rustc 1.25.0-nightly (3ec5a99aa 2018-02-14)
$ ion --version
ion 1.0.0-alpha (x86_64-unknown-linux-gnu)
rev 22b3efc6eb29020b452c44ad057c394951f6b982
```
https://gitlab.redox-os.org/redox-os/ion/-/issues/707Unterminated brace panic on `[{ }]`2018-06-10T02:59:05ZMichael Aaron Murphymmstick@pm.meUnterminated brace panic on `[{ }]`*Created by: xTibor*
**Reproduction**:
`user:~/git/ion# [{ }]`
**Expected behavior**:
A syntax error or some other kind of error message.
**Actual behavior**:
A panic with the following message: `thread 'main' panicked at 'ion:...*Created by: xTibor*
**Reproduction**:
`user:~/git/ion# [{ }]`
**Expected behavior**:
A syntax error or some other kind of error message.
**Actual behavior**:
A panic with the following message: `thread 'main' panicked at 'ion: fatal error with syntax validation: unterminated brace', src/lib/parser/shell_expand/words/mod.rs:519:9`
[Full backtrace](https://gist.github.com/xTibor/03eaec5d81cbc52b955ddfd676e09295)
**Build information**:
`rustc -V`: `rustc 1.26.0-nightly (2789b067d 2018-03-06)`
`git rev-parse HEAD`: 96d5b5d2ef53d8d9e93a4a41019560175cc12598
System: KDE neon 5.12 (Ubuntu 16.04 LTS)
https://gitlab.redox-os.org/redox-os/ion/-/issues/706freezes after "fg"ing suspended sleep2018-06-10T02:59:05ZMichael Aaron Murphymmstick@pm.mefreezes after "fg"ing suspended sleep*Created by: matthiaskrgr*
repo @ 96d5b5d2ef53d8d9e93a4a41019560175cc12598
in the ion shell, I did
````
sleep 5
*ctrl-z*
^Zion: bg [0] 19401
ion: ([0] 19401) exited with 0
*shell hangs*
````
ctrl-c or ctrl-d did not terminate...*Created by: matthiaskrgr*
repo @ 96d5b5d2ef53d8d9e93a4a41019560175cc12598
in the ion shell, I did
````
sleep 5
*ctrl-z*
^Zion: bg [0] 19401
ion: ([0] 19401) exited with 0
*shell hangs*
````
ctrl-c or ctrl-d did not terminate ion or got rid of the hang
I tried to attach gdb to the process and this is what I got:
````
#0 0x00007fee5e3ed260 in nanosleep () from /usr/lib/libpthread.so.0
#1 0x0000562b21af9941 in std::sys::unix::thread::Thread::sleep () at libstd/sys/unix/thread.rs:163
#2 std::thread::sleep () at libstd/thread/mod.rs:700
#3 0x0000562b21a54b77 in liner::history::History::new::{{closure}} () at /home/matthias/.cargo/registry/src/github.com-1ecc6299db9ec823/liner-0.4.4/src/history.rs:74
#4 0x0000562b21a52dd3 in std::sys_common::backtrace::__rust_begin_short_backtrace (f=...) at /checkout/src/libstd/sys_common/backtrace.rs:136
#5 0x0000562b21a76607 in std::thread::Builder::spawn::{{closure}}::{{closure}} () at /checkout/src/libstd/thread/mod.rs:406
#6 0x0000562b21a75723 in <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once (self=..., _args=()) at /checkout/src/libstd/panic.rs:296
#7 0x0000562b21a7682d in std::panicking::try::do_call (data=0x7fee5d5feae8 "@\361a]\356\177\000") at /checkout/src/libstd/panicking.rs:306
#8 0x0000562b21b18e6f in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:102
#9 0x0000562b21a76739 in std::panicking::try (f=...) at /checkout/src/libstd/panicking.rs:285
#10 0x0000562b21a75d3a in std::panic::catch_unwind (f=...) at /checkout/src/libstd/panic.rs:361
#11 0x0000562b21a76463 in std::thread::Builder::spawn::{{closure}} () at /checkout/src/libstd/thread/mod.rs:405
#12 0x0000562b21a7853f in <F as alloc::boxed::FnBox<A>>::call_box (self=0x7fee5d621150, args=()) at /checkout/src/liballoc/boxed.rs:783
#13 0x0000562b21b10d1c in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::hcd0ea510185709fe () at /checkout/src/liballoc/boxed.rs:793
#14 std::sys_common::thread::start_thread () at libstd/sys_common/thread.rs:24
#15 std::sys::unix::thread::Thread::new::thread_start () at libstd/sys/unix/thread.rs:90
#16 0x00007fee5e3e308c in start_thread () from /usr/lib/libpthread.so.0
#17 0x00007fee5df03e7f in clone () from /usr/lib/libc.so.6
````
meta:
````
Linux t470 4.14.24-1-MANJARO #1 SMP PREEMPT Sun Mar 4 21:28:02 UTC 2018 x86_64 GNU/Linux
rustc 1.26.0-nightly (2789b067d 2018-03-06)
````