Tab completion in OpenBSD's ksh(deftly.net)
deftly.net
Tab completion in OpenBSD's ksh
https://deftly.net/posts/2017-05-01-openbsd-ksh-tab-complete.html
3 comments
Where did the author get the idea that fish is 200k SLOC? They're wildly mis-counting.
Yes, `cloc` on a fresh checkout of fish-shell says there's 200k lines, but most of that isn't fish-shell source. Fully half of that is from PCRE. And if I run `cloc` on just the `src` directory I get 39k lines.
Yes, `cloc` on a fresh checkout of fish-shell says there's 200k lines, but most of that isn't fish-shell source. Fully half of that is from PCRE. And if I run `cloc` on just the `src` directory I get 39k lines.
Author here :) - I did all of the counts using the source tree (from tarball or cvs) of the respective shells.
Using just the `src` tree doesn't cut it imo, especially for fish, it installs lots of python scripts (fish_configure which sets up a python webserver, fish_update_completions which calls create_manpage_completions.py.. etc). Those count, and they are not included inthe src tree.
Using just the `src` tree doesn't cut it imo, especially for fish, it installs lots of python scripts (fish_configure which sets up a python webserver, fish_update_completions which calls create_manpage_completions.py.. etc). Those count, and they are not included inthe src tree.
`cloc` on the `share` folder (which contains all of the python webserver scripts) only adds another 10k. Also I'm not sure those should count when talking about shell complexity, because nearly all of that is strictly a helper tool that most people don't actually even run (fish_config), so isn't particularly meaningful for your day-to-day running of the shell.
Or to put it another way, running `cloc` on the full checkout is extremely misleading. You're counting PCRE and other stuff that aren't particularly relevant to talking about shell complexity. Find the specific folders you do care about (which I still maintain is just the src/ folder) and run `cloc` on those specific folders, not on the full checkout.
Or to put it another way, running `cloc` on the full checkout is extremely misleading. You're counting PCRE and other stuff that aren't particularly relevant to talking about shell complexity. Find the specific folders you do care about (which I still maintain is just the src/ folder) and run `cloc` on those specific folders, not on the full checkout.
Q: Where did the author get the idea that fish is 200k SLOC?
A: 'cloc' on a fresh checkout of fish-shell says there's 200k lines.
;)
A: 'cloc' on a fresh checkout of fish-shell says there's 200k lines.
;)
No matter how many of these lines you label as "fish" and "not-fish", they somehow all end up in "/usr/bin/fish".
Well, not necessarily. The linker will strip out any symbols that aren't actually used, which may indeed be a non-inconsequential chunk of fish's bundled dependencies.
That's not particularly meaningful. The author was making a statement about shell complexity by using lines of code, not making a statement about binary size. The fact that there's 113k CLOC of PCRE in there is pretty irrelevant to talking about the complexity of Fish itself.
A brand new kind of [nearly] POSIX compliant shell can be found here, in a little project called "Linux on the Web" (requires Chrome): https://linuxontheweb.appspot.com
The main JS file that implements it is currently showing less than 6k lines (which doesn't include the lexer/tokenizer, in another file, and adds another couple thousand).
I have seen silly toys in websites that have superficial resemblances to *nix shells, but this one seriously borders on 100% standards compliance. Most users will want to run this command upon system "bootup":
$ import fs
... which loads in a lot of typical filesystem related commands like cp, mv, rm, and less. The command to edit files is:
$ edit file_name.txt
... which you can throw a '-c' flag in order to create a new, empty file at the same time. Alt+s to save edits, Ctrl+x to exit. Several nano key bindings apply.
You can do something like this to see the gui in action:
$ import gui && desk
Then you are on the desktop. You can do an Alt+t to open the terminal while there. This is a decent video to start out with: https://www.youtube.com/watch?v=9tl8I8YcH7g
A couple other recent videos can then be found from there.
The main JS file that implements it is currently showing less than 6k lines (which doesn't include the lexer/tokenizer, in another file, and adds another couple thousand).
I have seen silly toys in websites that have superficial resemblances to *nix shells, but this one seriously borders on 100% standards compliance. Most users will want to run this command upon system "bootup":
$ import fs
... which loads in a lot of typical filesystem related commands like cp, mv, rm, and less. The command to edit files is:
$ edit file_name.txt
... which you can throw a '-c' flag in order to create a new, empty file at the same time. Alt+s to save edits, Ctrl+x to exit. Several nano key bindings apply.
You can do something like this to see the gui in action:
$ import gui && desk
Then you are on the desktop. You can do an Alt+t to open the terminal while there. This is a decent video to start out with: https://www.youtube.com/watch?v=9tl8I8YcH7g
A couple other recent videos can then be found from there.
I thought a fork/exec (seems like a core requirement for a shell) didn't inherit the pledge from the parent?