Cicada – Unix shell written in Rust

Post by falcolas » Sat, Jul 01, 2017, 1:31 PM UTC

kemayo wrote: post #71

gregopet wrote: post #68

Earlier quoted context omitted.

jq can't handle big numbers, it silently mangles them, beware! Was bitten by this twice already..

That's per the spec[1], enjoyably: Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values. 2^53 is only 9007199254740990, so it's not too hard to exceed that, particularly in things like twitter status ids. The recommended use is to have big numbers as strings, since it'…

Post by gkya » Sat, Jul 01, 2017, 1:41 PM UTC

sirn wrote: post #22

vidarh wrote: post #17

Earlier quoted context omitted.

The problem with modernising the shell stack is that there are a lot of things that depends on the current stack, be it the shell (e.g. see the amount of work it's taken for Ubuntu and Debian to switch to dash as /bin/sh; and dash has a pedigree going back to the 80's), or the upper layers (try to alias "ls" to something that acts differently, and see how many tools depend on parsing its output). You'd either have to…

This matches my experience trying to switch the login shell from bash to fish: a surprisingly amount of things failed. macOS users won't have this problem, as the login shell is only started when Terminal/iTerm is started, but in Linux pretty much every process rely on the fact that your $SHELL is POSIX-complaint. It seems like the way to go to use non-POSIX shell as the default shell without changing login shell, is…

Post by ofek » Sat, Jul 01, 2017, 1:45 PM UTC

brandur wrote: post #3

Amazing work! Between this, Alacritty [1], and coreutils [2], we're getting pretty close to a plausible all-Rust CLI stack. While Cicada is pretty clearly modeled on the "old" generation of shells (sh, Bash, Zsh, etc.), one has to wonder what a more modern shell might look to address some of the problems of its predecessors like pipes that are essentially text-only, poor composability (see `cut` or `xargs`), and terr…

Post by falcolas » Sat, Jul 01, 2017, 1:46 PM UTC

valarauca1 wrote: post #31

withjive wrote: post #4

Earlier quoted context omitted.

The fact that there is a "Won't do list" stating that functions won't be supported... I don't think this is anything more than a toy to play with rust.

Generally speaking anytime you start to breakout bash/zsh/sh/csh functions you've already entered a zone where just writing a python/perl script would be the easier and a more maintainable solution in the long term.

    export MARKPATH=$HOME/.marks
    function jump {
        cd -P $MARKPATH/$1 2> /dev/null || (echo "No such mark: $1" && marks)
    }
    function mark {
        mkdir -p $MARKPATH; ln -s $(pwd) $MARKPATH/$1
    }
    function unmark {
        rm -i $MARKPATH/$1
    }
    function marks {
        ls -l $MARKPATH | sed 's/  / /g' | cut -d' ' -f9- && echo
    }
    _jump()
    {
        local cur=${COMP_WORDS[COMP_CWORD]}
        COMPREPLY=( $(compgen -W "$( ls $MARKPATH )" -- $cur) )
    }
    complete -F _jump jump

Post by falcolas » Sat, Jul 01, 2017, 1:56 PM UTC

kemayo wrote: post #79

falcolas wrote: post #72

Earlier quoted context omitted.

I have to admit, I was not familiar with this limitation. Thanks for pointing it out. And I'd go from "kind of horrible" to just "horrible". Integral bit limits are an implementation detail that every language has a way to overcome - they shouldn't be built into an encoding spec.

Again, not saying this is a good thing, but it's an understandable consequence of the standardization partially involving "let's document how the browsers existing JS implementations deal with running eval on a string". It's easier to write the standard so that existing implementations fit it, rather than requiring changes from everyone.