hush
parsegen
hush | parsegen | |
---|---|---|
7 | 2 | |
627 | 15 | |
0.2% | - | |
2.9 | 1.5 | |
8 months ago | about 1 year ago | |
Rust | Rust | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
hush
-
Why should I care wether my shell is POSIX compliant?
If we're detaching from POSIX, why not get more wild? Why not xonsh or something? Also I found this lua inspired shell which could be cool: https://github.com/hush-shell/hush
-
Working with JSON in traditional and next-gen shells like Elvish, NGS, Nushell, Oil, PowerShell and even old-school Bash and Windows Command Prompt
Maybe hush (https://github.com/hush-shell/hush) should be included in this list.
- Hush – Unix shell based on the Lua programming language
- Hush - unix shell based on the Lua programming language
-
Guide: Hush Shell-Scripting Language
While being extremely small is a worthy goal, I suppose the aim of Hush is to make writing larger shell scripts easier and less error-prone. It's more for the niche of Perl of old than of minimal shells like ash.
For a very limited device, a very limited shell like that in Busybox is sufficient, because it likely does not need large shell scripts, or a lot of interactive work.
Looking at [1], current Hush is under 700k, which is still way smaller than Python or Perl, with much of its expressiveness.
[1]: https://github.com/hush-shell/hush/releases
-
Announcing Hush, a modern shell scripting language
Official guide: https://hush-shell.github.io/ Repository: https://github.com/hush-shell/hush
-
If you're not using a lexer generator for your compiler, why?
Yes, you can check the code here: https://github.com/gahag/hush
parsegen
-
How are macros dealt with for incremental compilation?
Indeed this is the problem I'm having with my proc macro crates lexgen and parsegen. In the case of lexgen, the proc macro is actually quite fast for realistic inputs, but the compiler spends a lot of time checking and generated code with cargo check (which I suspect rust-analyzer also uses). In the case of parsegen the proc macro does some analyses and takes some time. In both cases I have to split my proc macro code (not the proc macros, the code that uses the proc macros) to separate crates so that they won't be recompiler/re-analyzed as I work on the code.
-
If you're not using a lexer generator for your compiler, why?
I'm working on my own lexer and parser generators, and I'm trying to understand why some projects don't use lexer and parser generators and use hand-written lexers and parsers.
What are some alternatives?
busybox - BusyBox mirror
lexgen - A fully-featured lexer generator, implemented as a proc macro
busybox - Docker Official Image packaging for Busybox
logos - Create ridiculously fast Lexers
hush - hush (a Bourne-style shell) for the GNO multitasking environment on the Apple IIgs
u-boot - "Das U-Boot" Source Tree
ngs - Next Generation Shell (NGS)
Wormies-AU-Helpers - Helper scripts to make maintaining packages using AU even easier
Wren - The Wren Programming Language. Wren is a small, fast, class-based concurrent scripting language.
lash - A modern, robust glue language