ion issueshttps://gitlab.redox-os.org/redox-os/ion/-/issues2021-07-14T08:33:11Zhttps://gitlab.redox-os.org/redox-os/ion/-/issues/1006ArrayMethod and StringMethod implementation should be refactored into a gener...2021-07-14T08:33:11ZNils ErikssonArrayMethod and StringMethod implementation should be refactored into a generic method structurefeat: ArrayMethod and StringMethod are two structures with identical members (StringMethod members are all public).
These two are doing largely the same work (supplying methods to one of the objects, string or array) but the implementat...feat: ArrayMethod and StringMethod are two structures with identical members (StringMethod members are all public).
These two are doing largely the same work (supplying methods to one of the objects, string or array) but the implementation differs completely how the two structures does this. It feels like both of the files were written by two different persons at two different times.
ArrayMethod's methods largely defines each in-shell method in a separate source code method.
StringMethod only has one handle method and uses builtin macros, within the scope of the method. All logic are decided in a huge match block.
The logic behind Array and String methods has to work with the name of the variable directly and resolve it's value manually. Ideally you want to write functions that takes typed arguments which works with values directly and does not have to de reference variable names or initiate array expressions. That should be the job of a parser.
The method structures are kind of parsed, but it could be better.
If we look at ArrayMethod structure we will see a couple of problems. (StringMethod structure is the same)
```rust
pub struct ArrayMethod<'a> {
method: &'a str,
variable: &'a str,
pattern: Pattern<'a>,
selection: Option<&'a str>,
}
```
1. The ArrayMethod structure has it's method name as one of it's argument. This serves no purpose in the code which is the method, other than to call it. The ArrayMethod should be redesigned so to either not need to know the name of the method (the parser calls the method as soon as it has read the method name), or ArrayMethod is a composit structure which consists of a structure which has a method name member and an argument's member which is a structure containing the arguments strictly needed to perform the method operation.
2. The ArrayMethod has one variable argument. Should it not be an array of variables? We can make more interesting methods if we were working with more than one argument.
3. The ArrayMethod has a pattern member. The pattern member is an enum which looks like this:
```rust
pub enum Pattern<'a> {
StringPattern(&'a str),
Whitespace,
}
```
I've tested what's put inside it and it seams like anything after the first argument in a in-shell method is put inside StringPattern as raw text. (Correct me if I'm wrong). Here is the rest of the variables I want my method to work with, in raw script source text. Now I have to manually parse them.
4. The ArrayMethod has a selection member. I don't know what that is, but I have a feeling that it should be pre-parsed away.
I suggest we go back to the drawing board with how method parsing should be done as it is a bit of a mess of how it's implemented.
My suggestion of a generic method structure is just to have an array of preparsed variables. No variable names needed to be de-referenced. No array expression needing to be created. The array should be typed and its contents must match the intended methods signature to be able to run.
Example:
```rust
pub enum Typed<'a> {
Array(&'a [str]),
String(&'a str),
}
pub struct MethodStruct<'a> {
variables: &'a [Typed]
}
```
The three culprit files are hidden in `src/lib/expansion/methods/`
BREAKING CHANGE: Changes in the datastructure, internal
performance: Might improve
usability: Adding methods for either ArrayMethod or StringMethod should be easier.
maintainability: Should remove code, making it easier to maintain.
reason: Refactoring for refactorings sake.
PS.
I've been rambling on about ArrayMember and StringMember. I just think there can be a lot of improvements to the method parsing in the files mentioned and that something should be done before even more methods needs to be written.
Oh and also testing tools should be rewritten. Why not test with the real ion shell instead of manually inserting variables into the shell heap with the DummyExpander?https://gitlab.redox-os.org/redox-os/ion/-/issues/998vi-mode: `e` does not work properly2021-08-31T08:28:31Zmseravallivi-mode: `e` does not work properlyin VI normal mode the `e` navigation does not work properly, it misses the last character.
How to reproduce:
```
[input from keyboard: ESC i l o r e m SPACE i p s u m]
$ lorem ipsum
[input from keyboard: ESC 0 d e]
$ m ipsum
```
Exp...in VI normal mode the `e` navigation does not work properly, it misses the last character.
How to reproduce:
```
[input from keyboard: ESC i l o r e m SPACE i p s u m]
$ lorem ipsum
[input from keyboard: ESC 0 d e]
$ m ipsum
```
Expected result ` ipsum`
This happens as well if I try to change the word:
```
[input from keyboard: ESC i l o r e m SPACE i p s u m]
$ lorem ipsum
[input from keyboard: ESC 0 c e h e l l o]
$ hellom ipsum
```
Expected result `hello ipsum`Ion Shell v1.0.0https://gitlab.redox-os.org/redox-os/ion/-/issues/963bug: source-sh broken, improve documentation2020-12-16T00:59:25Zmaxice8bug: source-sh broken, improve documentationI'm trying to use `source-sh` to get some variables from an Alpine Linux APKBUILD into the environment of the Ion shell.
The APKBUILD looks like this:
```
# Contributor: dai9ah <dai9ah@protonmail.com>
# Maintainer: dai9ah <dai9ah@proto...I'm trying to use `source-sh` to get some variables from an Alpine Linux APKBUILD into the environment of the Ion shell.
The APKBUILD looks like this:
```
# Contributor: dai9ah <dai9ah@protonmail.com>
# Maintainer: dai9ah <dai9ah@protonmail.com>
pkgname=2bwm
pkgver=0.3
pkgrel=0
pkgdesc="Fast floating window manager"
url="https://github.com/venam/2bwm"
arch="all"
license="ISC"
makedepends="libxcb-dev xcb-util-keysyms-dev xcb-util-wm-dev xcb-util-xrm-dev"
options="!check" # no test suite
subpackages="$pkgname-doc"
source="$pkgname-$pkgver.tar.gz::https://github.com/venam/2bwm/archive/v$pkgver.tar.gz"
prepare() {
default_prepare
sed -i Makefile -e "/CFLAGS/{s/+=-Os /+=/}"
}
build() {
make
}
package() {
make PREFIX=/usr DESTDIR="$pkgdir" install
}
sha512sums="088a97e5245287890c72e2b0685f7348a4cc0fd49582893b7ce7a081f80a4d7454a3c0eadf4609589314351ded02fd8b75548019b782e797350ad5db5c939f92 2bwm-0.3.tar.gz"
```
After sourcing it with `source-sh` i expect the variables in the root of the document to be accessible from Ion.Ion Shell v1.0.0https://gitlab.redox-os.org/redox-os/ion/-/issues/914Missing end quote on export command generates weird errors2022-11-26T09:23:26ZSteven PeaseMissing end quote on export command generates weird errors```
export GEM_HOME="${HOME}/something
```
This can cause anywhere from `assignment error: GEM_HOME: variable does not exist` to `extra values were supplied, and thus ignored` depending on the following commands.
If this is intentional...```
export GEM_HOME="${HOME}/something
```
This can cause anywhere from `assignment error: GEM_HOME: variable does not exist` to `extra values were supplied, and thus ignored` depending on the following commands.
If this is intentional, I'm guessing the intention was to allow strings spanning newlines?
An error when there's an uneven number of quotation marks etc. would be nice to have.Ion Shell v1.0.0betamatu3bamatu3bahttps://gitlab.redox-os.org/redox-os/ion/-/issues/893Failed running Ion with AlpineLinux2021-06-01T17:24:11ZNiklas Rosencrantzniklasr@protonmail.comFailed running Ion with AlpineLinuxI tried building it in a dockerized AlpineLinux. It did build the target but there is an error message when I tried to execute commands (echo $0, pwd, ls...). I can try again with some other Linux but my first attempt with Alpine failed.I tried building it in a dockerized AlpineLinux. It did build the target but there is an error message when I tried to execute commands (echo $0, pwd, ls...). I can try again with some other Linux but my first attempt with Alpine failed.Ion Shell v1.0.0betahttps://gitlab.redox-os.org/redox-os/ion/-/issues/880Multiple LHS values with indexing using math assignment operates on entire array2020-12-12T23:10:27ZRoland KovácsMultiple LHS values with indexing using math assignment operates on entire array* ion revision: 04f7be9
* expected behavior: indexed assignment only applies to the index position.
```
$ let a:[int] = [0 0 0]
$ let b:int = 0
$ let a[1] b += 1 1
$ echo @a
1 1 1 # [0 1 0] expected
$ echo $b
1
```* ion revision: 04f7be9
* expected behavior: indexed assignment only applies to the index position.
```
$ let a:[int] = [0 0 0]
$ let b:int = 0
$ let a[1] b += 1 1
$ echo @a
1 1 1 # [0 1 0] expected
$ echo $b
1
```Ion Shell v1.0.0https://gitlab.redox-os.org/redox-os/ion/-/issues/857Tracking Issue: Fast math roadmap2021-06-01T11:49:38ZAdminXVIITracking Issue: Fast math roadmapMath is currently too slow. Proposed roadmap:
- [x] Default to integer, rather than float
- [ ] Store the types, rather than parsing back and forth
- [x] Use lexical for parsing, rather than the stdlibMath is currently too slow. Proposed roadmap:
- [x] Default to integer, rather than float
- [ ] Store the types, rather than parsing back and forth
- [x] Use lexical for parsing, rather than the stdlibIon Shell v1.0.0https://gitlab.redox-os.org/redox-os/ion/-/issues/844Out of bounds panics on map assignments2019-02-24T01:28:33ZNagy Tiborxnagytibor@gmail.comOut of bounds panics on map assignmentsStacktraces and repros looks similar, so I grouped them together.
**Reproduction #1**:
```
let map['='] = '='
```
Panics with: `thread 'main' panicked at 'byte index 9 is out of bounds of "'] = '='"', src/libcore/str/mod.rs:2027:9`
<d...Stacktraces and repros looks similar, so I grouped them together.
**Reproduction #1**:
```
let map['='] = '='
```
Panics with: `thread 'main' panicked at 'byte index 9 is out of bounds of "'] = '='"', src/libcore/str/mod.rs:2027:9`
<details>
<summary>Stacktrace</summary>
<pre>
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
1: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:70
2: std::panicking::default_hook::{{closure}}
at src/libstd/sys_common/backtrace.rs:58
at src/libstd/panicking.rs:200
3: std::panicking::default_hook
at src/libstd/panicking.rs:215
4: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:478
5: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:385
6: rust_begin_unwind
at src/libstd/panicking.rs:312
7: core::panicking::panic_fmt
at src/libcore/panicking.rs:85
8: core::str::slice_error_fail
at src/libcore/str/mod.rs:0
9: core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::Range<usize>>::index::{{closure}}
at /rustc/4c2be9c97fb60a01c545b8e8fa61e4247ae5c9b2/src/libcore/str/mod.rs:1768
10: <core::option::Option<T>>::unwrap_or_else
at /rustc/4c2be9c97fb60a01c545b8e8fa61e4247ae5c9b2/src/libcore/option.rs:386
11: core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::Range<usize>>::index
at /rustc/4c2be9c97fb60a01c545b8e8fa61e4247ae5c9b2/src/libcore/str/mod.rs:1768
12: core::str::traits::<impl core::ops::index::Index<I> for str>::index
at /rustc/4c2be9c97fb60a01c545b8e8fa61e4247ae5c9b2/src/libcore/str/mod.rs:1633
13: <ion_lexers::arguments::ArgumentSplitter<'a> as core::iter::iterator::Iterator>::next
at members/lexers/src/arguments.rs:148
14: <ion_shell::parser::assignments::actions::AssignmentActions<'a> as core::iter::iterator::Iterator>::next
at src/lib/parser/assignments/actions.rs:79
15: <ion_shell::shell::Shell as ion_shell::shell::assignments::VariableStore>::local
at src/lib/shell/assignments.rs:167
16: <ion_shell::shell::Shell as ion_shell::shell::flow::FlowLogic>::execute_statement
at src/lib/shell/flow.rs:181
17: <ion_shell::shell::Shell as ion_shell::shell::flow::FlowLogic>::on_command
at src/lib/shell/flow.rs:491
18: ion_shell::shell::binary::terminate::terminate_script_quotes
at /home/tibor/git/ion/src/lib/shell/binary/terminate.rs:37
19: <ion_shell::shell::Shell as ion_shell::shell::binary::Binary>::terminate_script_quotes
at /home/tibor/git/ion/src/lib/shell/binary/mod.rs:165
20: ion_shell::shell::Shell::execute_script
at /home/tibor/git/ion/src/lib/shell/mod.rs:207
21: ion::main
at src/main.rs:54
22: std::rt::lang_start::{{closure}}
at /rustc/4c2be9c97fb60a01c545b8e8fa61e4247ae5c9b2/src/libstd/rt.rs:64
23: std::panicking::try::do_call
at src/libstd/rt.rs:49
at src/libstd/panicking.rs:297
24: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:92
25: std::rt::lang_start_internal
at src/libstd/panicking.rs:276
at src/libstd/panic.rs:388
at src/libstd/rt.rs:48
26: std::rt::lang_start
at /rustc/4c2be9c97fb60a01c545b8e8fa61e4247ae5c9b2/src/libstd/rt.rs:64
27: main
28: __libc_start_main
29: _start
</pre>
</details>
<br>
**Reproduction #2**:
```
let map[=]
```
Panics with: `thread 'main' panicked at 'index out of bounds: the len is 4 but the index is 4', members/lexers/src/assignments/keys.rs:67:16`
<details>
<summary>Stacktrace</summary>
<pre>
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
1: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:70
2: std::panicking::default_hook::{{closure}}
at src/libstd/sys_common/backtrace.rs:58
at src/libstd/panicking.rs:200
3: std::panicking::default_hook
at src/libstd/panicking.rs:215
4: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:478
5: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:385
6: rust_begin_unwind
at src/libstd/panicking.rs:312
7: core::panicking::panic_fmt
at src/libcore/panicking.rs:85
8: core::panicking::panic_bounds_check
at src/libcore/panicking.rs:61
9: ion_lexers::assignments::keys::KeyIterator::parse_array
at members/lexers/src/assignments/keys.rs:67
10: <ion_lexers::assignments::keys::KeyIterator<'a> as core::iter::iterator::Iterator>::next
at members/lexers/src/assignments/keys.rs:153
11: <ion_shell::parser::assignments::actions::AssignmentActions<'a> as core::iter::iterator::Iterator>::next
at src/lib/parser/assignments/actions.rs:78
12: <ion_shell::shell::Shell as ion_shell::shell::assignments::VariableStore>::local
at src/lib/shell/assignments.rs:167
13: <ion_shell::shell::Shell as ion_shell::shell::flow::FlowLogic>::execute_statement
at src/lib/shell/flow.rs:181
14: <ion_shell::shell::Shell as ion_shell::shell::flow::FlowLogic>::on_command
at src/lib/shell/flow.rs:491
15: ion_shell::shell::binary::terminate::terminate_script_quotes
at /home/tibor/git/ion/src/lib/shell/binary/terminate.rs:37
16: <ion_shell::shell::Shell as ion_shell::shell::binary::Binary>::terminate_script_quotes
at /home/tibor/git/ion/src/lib/shell/binary/mod.rs:165
17: ion_shell::shell::Shell::execute_script
at /home/tibor/git/ion/src/lib/shell/mod.rs:207
18: ion::main
at src/main.rs:54
19: std::rt::lang_start::{{closure}}
at /rustc/4c2be9c97fb60a01c545b8e8fa61e4247ae5c9b2/src/libstd/rt.rs:64
20: std::panicking::try::do_call
at src/libstd/rt.rs:49
at src/libstd/panicking.rs:297
21: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:92
22: std::rt::lang_start_internal
at src/libstd/panicking.rs:276
at src/libstd/panic.rs:388
at src/libstd/rt.rs:48
23: std::rt::lang_start
at /rustc/4c2be9c97fb60a01c545b8e8fa61e4247ae5c9b2/src/libstd/rt.rs:64
24: main
25: __libc_start_main
26: _start
</pre>
</details>
<br>
**Build information**:
`rustc -V`: rustc 1.33.0-nightly (4c2be9c97 2019-01-22)
`git rev-parse HEAD`: 918e1fc427e9700eb1d11c121544ac8f7c497972https://gitlab.redox-os.org/redox-os/ion/-/issues/833HISTORY_TIMESTAMP = 1 messes up history scrolling2019-04-02T17:00:03ZthedukeHISTORY_TIMESTAMP = 1 messes up history scrollingWith `let HISTORY_TIMESTAMP = 1`, browsing the history does not work correctly.
It will show a history entry for each timestamp instead of skipping those lines in the history file.With `let HISTORY_TIMESTAMP = 1`, browsing the history does not work correctly.
It will show a history entry for each timestamp instead of skipping those lines in the history file.https://gitlab.redox-os.org/redox-os/ion/-/issues/705Add `type`-builtin instead of `which`2021-06-01T13:57:01ZMichael Aaron Murphymmstick@pm.meAdd `type`-builtin instead of `which`*Created by: LeonardKoenig*
**Description**: `which` is a remnant of csh and behaves on many shells differently, `type` has since replaced it as a portable and standardized alternative, cf. https://unix.stackexchange.com/questions/85249...*Created by: LeonardKoenig*
**Description**: `which` is a remnant of csh and behaves on many shells differently, `type` has since replaced it as a portable and standardized alternative, cf. https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then
**Proposed change**: Add `type` shell-builtin, possibly deprecate/remove `which`.Ion Shell v1.0.0https://gitlab.redox-os.org/redox-os/ion/-/issues/463Move `shell::signals` and `shell::pipe::crossplat` to `sys`2018-06-12T14:22:02ZMichael Aaron Murphymmstick@pm.meMove `shell::signals` and `shell::pipe::crossplat` to `sys`*Created by: huntergoldstein*
Keeping all of the platform specific stuff under the `sys` module would be neater than having it spread around the project.*Created by: huntergoldstein*
Keeping all of the platform specific stuff under the `sys` module would be neater than having it spread around the project.https://gitlab.redox-os.org/redox-os/ion/-/issues/378Refactor Job Control2018-06-18T16:32:11ZMichael Aaron Murphymmstick@pm.meRefactor Job ControlThe job control portions of the codebase are in a bit of a mess right now, so I think it's pretty important that we spend time refactoring it to increase maintainability in the future.
- [x] Forking
- [x] Signals
- [ ] Background M...The job control portions of the codebase are in a bit of a mess right now, so I think it's pretty important that we spend time refactoring it to increase maintainability in the future.
- [x] Forking
- [x] Signals
- [ ] Background Managementhttps://gitlab.redox-os.org/redox-os/ion/-/issues/337Move `calc` logic to a separate crate2018-06-12T14:22:03ZMichael Aaron Murphymmstick@pm.meMove `calc` logic to a separate crate*Created by: huntergoldstein*
# Pros
* Permits faster iteration and more experimentation
* Sufficiently decouples the current `calc` monolith from the rest of `ion`
* Allows other applications to easily make use of `calc`'s logic
...*Created by: huntergoldstein*
# Pros
* Permits faster iteration and more experimentation
* Sufficiently decouples the current `calc` monolith from the rest of `ion`
* Allows other applications to easily make use of `calc`'s logic
# Cons
* Adds another dependency
* Version differences may cause incompatibilities (for example if some byte sequence is always special in `ion` but is used for a particular purpose in `calc`)https://gitlab.redox-os.org/redox-os/ion/-/issues/299use HISTFILE instead of HISTORY_FILE2018-06-12T14:22:03ZMichael Aaron Murphymmstick@pm.meuse HISTFILE instead of HISTORY_FILE*Created by: mallochine*
There's probably some context I'm missing here, but shouldn't the shell be using "HISTFILE" instead of "HISTORY_FILE"? HISTFILE is the standard bash variable:
https://www.gnu.org/software/bash/manual/html_nod...*Created by: mallochine*
There's probably some context I'm missing here, but shouldn't the shell be using "HISTFILE" instead of "HISTORY_FILE"? HISTFILE is the standard bash variable:
https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.htmlhttps://gitlab.redox-os.org/redox-os/ion/-/issues/231Refactoring Plans2018-06-12T14:22:05ZMichael Aaron Murphymmstick@pm.meRefactoring PlansI think it'd be best if we separated builtins from existing modules and placed them into their own `builtins` module. No need to have them embedded within existing structures. Perhaps one file per builtin command.
In addition, the `Co...I think it'd be best if we separated builtins from existing modules and placed them into their own `builtins` module. No need to have them embedded within existing structures. Perhaps one file per builtin command.
In addition, the `Command` structure in the main source file should also go into the `builtin` module and perhaps have it's name changed from `Command` to `Builtin`, as these commands are built in. To do this, the `Shell` structure and all of it's methods would have to be separated into it's own `shell` module too.
Finally, it's probably best if the builtins are statically generated at compile time, instead of regenerating them each time a command is evaluated.
### Refactor Shell/Command Structures
- [x] Shell -> shell.rs
- [x] Command -> builtin/mod.rs
- [x] Split Flow Control Logic Into Flow Logic Module
### Builtins Refactoring Progress
- [x] alias
- [x] unalias
- [x] let
- [x] drop
- [x] export
- [ ] cd
- [ ] dirs
- [ ] pushd
- [ ] popd
- [ ] read
- [ ] exit
- [ ] history
- [x] source
- [ ] true
- [ ] false
- [ ] help