mitnk/cicada

An old-school bash-like Unix shell written in Rust

cicada's Issues

Line parse issue - escape quotes inside quotes

Case 1:

expected (bash):

$ echo '{"q": "{\"size\": 12}"}'
{"q": "{\"size\": 12}"}

actual (cicada 0.7.2):

$ echo '{"q": "{\"size\": 12}"}'
{"q": "{"size": 12}"}

Case 2:

expected:

$ echo '{\"size\": 12}'
{\"size\": 12}
$ echo '{\"size\": 12}' | wc -c
15

actual:

$ echo '{\"size\": 12}'
{"size": 12}
$ echo '{\"size\": 12}' | wc -c
13

Pipeline Stuck when its Latter Commands Finished First

cicada still has a bad issue that it stuck when the latter commands finish first. For example,

$ ps ax | head -n 3

If your system run a lot of programs, this pipeline will stuck, though you can hit CTRL+C to escape.
Note: ps ax | tail does not suck.

USER       PID  PPID  PGID TPGID STAT COMMAND
mitnk     9471  9470  9470  9582 S    -cicada
root      9582  9471  9582  9582 S+   ps ax
mitnk     9583  9471  9582  9582 Z+   (head)

If the above command didn't stuck on your side (ps has less items), you can create a file with huge lines in it, then the following command will do:

$ cat file-with-100k-lines.txt | head -n 3

Logically, when the second command finish its job, will terminate and close its resource, the output of the pipe; then the first (still running) command noticed (when trying write to) the pipe is closed, it will terminate too.

I haven't tackled it yet. Maybe a signal handle issue, maybe not.

Is it aiming to become an actual POSIX-compatible shell?

If yes then functions should also be in the todo list instead of won't do.

kind: InvalidData

cicada echo $HOSTNAME
cicada: read_to_string error: Custom { kind: InvalidData, error: StringError("stream did not contain valid UTF-8") }

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"
NAME="Ubuntu"
VERSION="18.04.2 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.2 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

uname -a
Linux think 4.18.0-24-generic #25~18.04.1-Ubuntu SMP Thu Jun 20 11:13:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

entity not found

Trying out this simple script for timing operation. Is the entity not found lines a bug? They seem similar to #9 with exit.

time ./cicada -c 'for i in $(seq 1 1000000);do [ 1 = 1 ];done'
for: entity not found
do: entity not found
done: entity not found

real    0m0.172s
user    0m0.129s
sys     0m0.050s

Here is the equivalent for dash:

$ time dash -c 'for i in $(seq 1 1000000);do [ 1 = 1 ];done'

real    0m0.748s
user    0m0.708s
sys     0m0.021s

Optionally import Bash history into sqlite database on first run

It would be nice if, upon first run (i.e., the cicada history database does not yet exist), the user could be prompted to import their Bash history into the database. If no date exists for an entry then it would use the current timestamp, otherwise it would use the provided timestamp from the .bash_history file:

Example .bash_history with timestamps

#1603194812
startx
#1603195328
vim .inputrc

implementation of pipes does not work

Try in Cicada:

yes | cat | head -n 3

which should finish. In Cicada, it does not.

Is BUILD_DATE stale without a prior `make clean`, for successive `make` calls?

How do you ensure that the BUILD_DATE env var from here:

cicada/src/build.rs

Line 15 in 340e813

println!("cargo:rustc-env=BUILD_DATE={}", tm.rfc822());

is being updated upon each successful compilation, without having to manually make clean before make ?

If my understanding is correct(and I tested this a lil bit on my test project), cargo caches the output of build.rs and if you just touch src/main.rs for example, but not also touch build.rs, it will use the cached output and thus BUILD_DATE(and GIT_HASH for that matter) will be the stale one.

Color Runnable cmd in Inputs

$ man sed | grep version
  ^ green   ^ green
      ^ black    ^ black

exit: entity not found

Not expected:

$ echo 'echo 1;exit;echo 2'|./target/debug/cicada
1
exit: entity not found
2

Expected (in bash):

$ echo 'echo 1;exit;echo 2'|bash
1

This does work as expected though:

$ echo -e 'echo 1;exit;echo2' >a && chmod u+x a && ./target/debug/cicada ./a
1

Vi mode?

Is there any interest in adding in a Vi mode for editing commands, similar to what set -o vi does in Bash? I find this mode very useful compared to using arrow keys.

[Question] Does this shell adhere to POSIX specifications, or plan to adhere to POSIX specifications?

Essentially the title. I am asking if this shell plans to adhere to POSIX specifications, as in, will it be usable as a POSIX shell replacement for /bin/sh on unix-like systems and usable for running POSIX shell script? i would love to hear the answer.

[Feature] Auto-complete

Did you saw this in Nu? Its simply amazing. I have an idea to make our own approach.

*A* Unix shell

small systems

hi, any chance to have this for very small systems? that is no-std?

cicada seems to have trouble with certain bash function names

Case in point being git's completion script, trying to run source ~/.git-prompt.sh from inside cicada throws with cicada: __git_ps1_show_upstream: command not found.

So far I have tried the following things:

• Drop the leading underscores in function names: No change
• Add the function keyword before function names: No change
• Mark ~/.git-prompt.sh as executable, add a bash shebang and directly execute it using ~/.git-prompt.sh: Execution succeeds but that doesn't resolve our use-case of needing those functions in the current shell.

I'll be glad to follow up with any additional debugging you'd like me to do.

support for multiple config files

I usually like to have my aliases, exports, etc. separated into separate files so its easier to read.
And then inside .bashrc or .bash_profile I would import them in.
Currently, cicada does not work with multiple files I think, or am I doing this wrong?

Thanks!

My bash script for importing files:

SHELL=cicada

INCLUDE_FILES=( \
	"$HOME/.config/$SHELL/dirs.sh" \
	"$HOME/.config/$SHELL/alias.sh" \
	"$HOME/.config/$SHELL/exports.sh" \
)

for FILE in ${INCLUDE_FILES[@]}; do
	if [ -f "$FILE" ]; then
		source "$FILE"
	fi
done

[Question] Does it fallback to Bash on some conditions?

shell fails to reap child processes in a timely manner

If you run

sleep 5 &
sleep 200

The first command should be reaped after 5 seconds, not after 200.

Similarly, if you run

sleep 1 &

this job isn't reaped until the user hits Enter again.

Support accessing subprocess stdin/out as file

Bash supports getting the FD of an opened pipe directly in the form /dev/fd/X which then can be used as file path by the spawned process.

Expected:

$ head <(echo a) <(echo b)
==> /dev/fd/63 <==
a

==> /dev/fd/62 <==
b

Got:

$ head <(echo a) <(echo b)
head: <echo: No such file or directory
head: a: No such file or directory
head: <echo: No such file or directory
head: b: No such file or directory

Same for >(CMD) which will use stdin instead of stdout.

[Feature Request]: Full 8 color prompts

Hello! this project looks nice, been using cicada shell for a while and i like it, however i noticed the prompts seem to lack the full 8 color spectrum which is standard on tty's, i would appreciate if these colors could be added to the shell prompts! thanks!

Use as a library

It would be useful to provide functions to

1. Parse input and return if it's complete and chunk it into individual command units (so e.g. a single command execution on its own line or an if statement are both individual command units)
2. Execute code and capture output

The idea is that we can then use it e.g. to power a Jupyter kernel or other alternative interfaces

feature : use ~/.config/cicada instead of .cicadarc

Hi,

Thanks for your shell
As many people complain about $HOME being a mess of dotfiles, I'd suggest using $XDG_HOME_CONFIG
Have a nice day

Please review your dependencies.

HI,

I'm the author of https://github.com/dpc/crev/tree/master/cargo-crev - a tool for keeping check of your dependencies.

I was doing review of crates from https://crates.io/users/IvanUkhov, since I had previous instances when I accidentally used a poor quality dependency from this user, and it looks like he has a lot of poor quality, incomplete, name-squatting crates. One of them is sqlite which you seem to be using.

I have not found any problems with that crate, but since it's a FFI crate, and I'm suspicious of this user, I would advise double-checking it, and maybe considering altneratives.

I would also advise to try https://github.com/dpc/crev/tree/master/cargo-crev, which might help with identifying problems like this in the future.

Cicada not quitting on SIGINT

First, thanks! Looks like a really cool project.

Cicada does not quit correctly when sent a SIGINT signal.
If sent externally, simply nothing is happening.
If sent through typing Ctrl-C directly in the shell, my terminal closes output, but cicada keeps running.
The terminal is then spammed with readline error: Error { repr: Os { code: 5, message: "Input/output error" } }, due to the closed stdout. At this point cicada consumes 100% of the CPU.

You should handle external signals and correctly quit the application.
(I also expected to be able to quit the shell using Ctrl-D aka sending EOF, but this does nothing

Webassembly and WASI as a compile target?

I think it would be the first WASI shell, Which has many benefits, for example in WASI lightweight containers or in projects like webassembly.sh.

cicada fails to recognize stopped jobs

Type:

vim &
ps f
jobs

it outputs:

$ vim &
[1] 17305
$ ps f
  PID TTY      STAT   TIME COMMAND
...
16964 pts/7    S      0:02  \_ target/debug/cicada
17305 pts/7    T      0:00      \_ vim
17307 pts/7    R+     0:00      \_ ps f
$ jobs
[1] 17305  Running    vim &
$ 

even though vim is stopped (T) cicada reports it as running.

Better Lib APIs

via #3

We need to rename line_to_tokens to cmd_to_tokens.

it would be also cool to have it indicate if the command is complete
e.g. the return value of line_to_tokens("foo |") should make clear
that this isn’t a runnable command.