I know I may be downvoted/flamed on this, but why doesn't everyone start looking at powershell as the default shell. All the default parameters you are looking for are already there. Plus, you can you use all the other standard shell tools
Bash 5.0 released
211–220 of 306 posts
Re: Bash 5.0 released
#212Earlier quoted context omitted.
Syntactic sugar is a phrase permanently marred for me by the ruby community: it means "cognitive load for other people who know the language but don't keep up with the faddy bits". It made me tremendously sad.
Yeah, but C-style "for" loops are nice, right ? Still, they really are a syntactic sugar for a "while". The problem is more with a language having fady bits and people using them when they don't make the code clearer, than with syntactic sugar.
Sure, I agree actually - if you are going to have a language that has lots of nice syntax, _let it be built in from the start_. Or only released at major increments, etc etc.
Re: Bash 5.0 released
#213Why did we keep the language of the shell and the OS separate? It seems like a needless abstraction which creates more harm than good (read a shell script vs any other language). While I'm at it, why is the filesystem and syscall api not just part of a standard userland language? For example, the filesystem could be exposed like an object tree rather than some syscall ritual. The syscalls could just be invisible, whe…
If you think of the browser as an OS, which it almost is these days, JavaScript is that language.
Re: Bash 5.0 released
#214I can’t imagine what BASH_ARGV0 is for. Can someone more sage supply an example of what problem it solves?
A use-case I've long wanted it for is better "--help" messages. If you want to tell the user how to invoke the program again, argv[0] is the right thing: Given: #include int main(int argc, char *argv[]) { printf("Usage: %s [OPTIONS]\n", argv[0]); return 0; } Running it as `./dir/demo --help` gives: Usage: ./dir/demo [OPTIONS] Put it somewhere in $PATH, and run it as `demo --help`, and it will give: Usage: demo [OPTIO…
Personally, I just don't bother trying to show the user their particular invocation:
#!/bin/bash
echo "Usage: $(basename $0) [OPTIONS]"Re: Bash 5.0 released
#215Earlier quoted context omitted.
I have a different theory; perhaps line printers (which terminals try to emulate) are to blame. Space on a line is limited and one directional, so thr tools naturally evolved towards strange single line incantations instead of full fledged programs. Commodore Pet did it right by introducing a navigable terminal where you could move between lines and don't need to open an editor to write multiline programs.
I don't have time to Google now but I think that mainframe terminals worked like that. 3270 should be the model to search for.
This was already a solved problem in the 70s. IBM's 3270 series offered full buffered access to a character matrix display, and DEC's VT52 and later terminals added bi-directional scrolling.
Modern CLIs can usually emulate at least a few of the old scrolling character matrix displays, but only a few bash commands (e.g. top) use the extra features.
Re: Bash 5.0 released
#216Earlier quoted context omitted.
It's strange to me to imagine that there would be one language that was the best choice for OS implementation and day to day user interaction/automation. I'm curious what language do you think would be good for both use cases?
A more syntactically friendly Haskell-like language
Haskell's lazy-by-default evaluation makes it more difficult to reason about memory usage, because it is all too easy to accidentally build up large expression trees at runtime [1]. This makes it a rather bad choice for a kernel or other low-level stuff.
Compare Rust, which tries to keep allocations (and the size/asymptotic complexity of allocations) explicit and visible.
[1] The optimizer catches some cases, but not all of them.
Re: Bash 5.0 released
#217Earlier quoted context omitted.
(re: Bash-vs-OS integration) bash is a programming language like any other, and you could use anything with a REPL as your shell. Python should do. In fact, I'll try it right now.. Yes, it works. Just sudo chsh -s /usr/bin/python and off you go. Once you start doing this for a bit, you'll notice that the Python REPL is an incredibly poor UI for repeated execution of subprocesses. It is very elaborate. Having to const…
> Python REPL is an incredibly poor UI for repeated execution of subprocesses Python REPL, even with recent additions of TAB completion, is a poor REPL, period. IPython, on the other hand, offers a much better programming environment than shell while still allowing easy access to most of the things you mention. Example: In [1]: from pathlib import Path In [2]: file = Path("~/.sbclrc").expanduser().read_text() In [3]:…
> In [3]: !echo "$file" | awk '!/^;;/'
That's Bash (or at least sh). Which excels at piping the output of programs into other programs, and pay that cost for everything else.
Re: Bash 5.0 released
#218Earlier quoted context omitted.
A use-case I've long wanted it for is better "--help" messages. If you want to tell the user how to invoke the program again, argv[0] is the right thing: Given: #include int main(int argc, char *argv[]) { printf("Usage: %s [OPTIONS]\n", argv[0]); return 0; } Running it as `./dir/demo --help` gives: Usage: ./dir/demo [OPTIONS] Put it somewhere in $PATH, and run it as `demo --help`, and it will give: Usage: demo [OPTIO…
Personally, I just don't bother trying to show the user their particular invocation: #!/bin/bash echo "Usage: $(basename $0) [OPTIONS]"
Minor nitpick, but wouldn't ${0##*/} work as well?
Re: Bash 5.0 released
#219Earlier quoted context omitted.
How does function sound for a syntactic sugar? $ today() { date +%F; } $ echo Today, $(today) is a great day! Today, 2019-01-08 is a great day!
It's not as nice, "cat $today" is easier to type than "cat $(today)" and would give better completion, just declared matching variables instead of matching functions, files and executables. On the plus side, TIL the subshell syntax plays well with eval/expand shortcut (ctrl+alt+e).
* "cat $today" is easier to type than "cat $(today)"*
Except you should really be in the habit of typing "cat ${today}" ;)
Re: Bash 5.0 released
#220Earlier quoted context omitted.
> Python REPL is an incredibly poor UI for repeated execution of subprocesses Python REPL, even with recent additions of TAB completion, is a poor REPL, period. IPython, on the other hand, offers a much better programming environment than shell while still allowing easy access to most of the things you mention. Example: In [1]: from pathlib import Path In [2]: file = Path("~/.sbclrc").expanduser().read_text() In [3]:…
> In [3]: !echo "$file" | awk '!/^;;/' That's Bash (or at least sh). Which excels at piping the output of programs into other programs, and pay that cost for everything else.
Yep. IPython lets you execute bash.