ast
Shell
ast | Shell | |
---|---|---|
4 | 1 | |
526 | 0 | |
0.0% | - | |
0.0 | 10.0 | |
about 1 year ago | over 1 year ago | |
C | C | |
Eclipse Public License 1.0 | GNU General Public License v3.0 only |
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.
ast
-
A Generation Lost in the Bazaar (2012)
I suspect the intended point of comparison is the monolithic Unix of old, where the entirety of the code of the system is (hopefully, ostensibly, allegedly) developed with a single vision, except for the applications in the narrowest sense of the word (e.g. the particular piece of numerics you need to design your airplane or whatnot, but not the editor you used to write it, the cluster scheduler you used to run it, the typesetter you used to write down your results, or the 3D viewer you used to present them).
One example that’s just plain interesting to read to see what things people were exploring (because, let’s admit it, historical Unix source gets plain boring after a while) is AT&T Research’s https://github.com/att/ast.
- Syntax Highlighting for OpenBSD's pdksh(1)?
-
Showing GUIs from Shell Scripts
Aha, I shall have a dig through https://github.com/att/ast/tree/master/src/lib/libtksh then.
Thank you kindly.
Shell
-
Give me your feature ideas for a C-like
Concerning the nested typedefs, yes, it's mainly just about nice code organization for me, but there are definitely other usecases where it's pretty essential, I'd say mostly in generic programming. I stumbled hard on this one: when writing a linked list - for each linked list variant, you have a node type, and a handle type that carries reference to the first node and other metadata like list length etc. . But you need to somehow be able to deduce the concrete handle type from the concrete node instance, so that the user can obtain handle instance by calling list_init() macro on the node and do other convenient stuff. Best solution I found so far how to solve this runtime-overhead-free in og GCC C is by defining zero-length array of the handle type inside the node type (like here) and then using __typeof__(node->_handle_typeinfo[0]) or something like that xDD, which is just so insanely ugly.
What are some alternatives?
ksh - ksh 93u+m: KornShell lives! | Latest release: https://github.com/ksh93/ksh/releases
hardv - A Powerful Flashcard Program for Linux, macOS, and Other Unix-like Systems
minishell - A simplified bash-like shell, with pipes, redirections and variable expansion.
chaotix - The chaotix operating system! (Previously known as Magma or Psychix)
oksh - Portable OpenBSD ksh, based on the Public Domain Korn Shell (pdksh).
Narthex - Modular personalized dictionary generator.
vCoolor.vim - Simple color selector/picker plugin for Vim.
shsub - Fast Template Engine for Shell
yad - Yet Another Dialog
c3c - Compiler for the C3 language
dotfiles
Alpine.js - A rugged, minimal framework for composing JavaScript behavior in your markup.