Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bash 5.0 released

lists.gnu.org

Post reply on HN
Print view View original

271–280 of 306 posts

Re: Bash 5.0 released

#271

Post by nine_k »

jxy wrote: post #57
charlesdaniels wrote: post #29

Earlier quoted context omitted.

If you're doing it right, you are solving very different problems with shell vs any other language. Shell is best used as a tool for orchestrating other programs, you should not be implementing your programs in shell. Syscalls, in general, are used in lieu of objects or other abstractions because they more accurate mirror what the underlying hardware is doing. This isn't always the case, some syscalls are maintained…

It's odd not including Plan 9 here. But I guess that is the fate of Plan 9.

It has already pushed the boundaries, and now seems not to be developed or used that actively.

Re: Bash 5.0 released

#272

Post by ris »

> The `history` builtin ... understands negative arguments as offsets from the end of the history list

At last!

Re: Bash 5.0 released

#273

Post by wicket »

xnyan wrote: post #268
wicket wrote: post #263

Earlier quoted context omitted.

Thanks for all the suggestions. Unfortunately zsh and fish are more bloated than bash, and dash and ksh are missing the features I use. I've just found "yash" which looks like a nice compromise. I'm going to give that a try.

If I may humbly ask, what is your definition of bloated? Bloated in technical sense that the software does not operate within your determined hardware constraints (valid!) or the philosophical sense that it has more features than your needs (also valid of course)?

My definition aligns with both definitions you described. Although I don't really have any hardware constraints that would stop me from running bash, zsh or fish, so my reasons for not wanting to use them, probably align better with your second definition.

However, I wouldn't consider the second definition to be philosophical, but technical. It has more features than my needs, therefore it has more lines of code, potentially more bugs, uses more memory and has a greater attack surface.

Re: Bash 5.0 released

#274

Post by _kst_ »

aexaey wrote: post #131
_kst_ wrote: post #84

With this release, bash now has three built-in variables (um, I mean "parameters") whose values are updated every time they're read: $RANDOM yields a random integer in the range 0..32767. (This feature was already there.) $EPOCHSECONDS yields the whole number of seconds since the epoch. $EPOCHREALTIME yields the number of seconds since the epoch with microsecond precision. I'm thinking of a new shell feature that wou…

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!

Not as good. I use $today a lot in file and directory names, The overhead of having to type $(today) rather than $today would be, for me, significant.

I do have a workaround for this particular case:

    PROMPT_COMMAND='today=$(printf "%(%F)T\n" -1)'
but it only works in bash 4.2 and later.

I could use

    PROMPT_COMMAND='today=$(date +%F)'
but I'm trying to avoid executing an external command on every prompt. (Maybe the overhead is low enough that it's not worth worrying about.)

My thoughts are (a) if user-defined special variables like this were a shell feature, I could find other uses for them and (b) it seems neater to make such a feature available to users rather than restricting it to three special-case built-in variables.

On the other hand, it might have been cleaner for $RANDOM, $EPOCHSECONDS, and $EPOCHREALTIME to be implemented as built-in functions rather than as special variables.

Re: Bash 5.0 released

#275

Post by wj »

LukeShu wrote: post #38
BurritoAlPastor wrote: post #21

I 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…

I'd love to see --help start with a few examples of the most common use cases and the parameters you would use. Include the exhaustive list of parameters after that. That would make the command line much more accessible for a significant portion of users. Or at least me. I'm always forgetting the syntax of commands I use infrequently.

Re: Bash 5.0 released

#276

Post by adwn »

Risord wrote: post #269
int_19h wrote: post #103

Earlier quoted context omitted.

How would you deal with mutable state like, say, the current directory?

I think that if we use purish FP as our system language it doesn't make sense to just emulate imperative/mutable system. But mm... why you would want to mutable state like current directory in first place? Or even mutable filesystem? Why aren't those just immutable parameters of your program?

> But mm... why you would want to mutable state like current directory in first place? Or even mutable filesystem? Why aren't those just immutable parameters of your program?

Because that's how just about any OS, application, library, filesystem, device driver, database, nearly everything related to computing at all, works. Reinventing the universe has never, ever lead to success. If you want even the slightest hope for non-negligible adoption of your operating system, you need to be able to interface with the rest of the world. And that's why you don't want the filesystem to be an "immuatble parameter of your program".

Re: Bash 5.0 released

#277

Post by charlesdaniels »

jxy wrote: post #57
charlesdaniels wrote: post #29

Earlier quoted context omitted.

If you're doing it right, you are solving very different problems with shell vs any other language. Shell is best used as a tool for orchestrating other programs, you should not be implementing your programs in shell. Syscalls, in general, are used in lieu of objects or other abstractions because they more accurate mirror what the underlying hardware is doing. This isn't always the case, some syscalls are maintained…

It's odd not including Plan 9 here. But I guess that is the fate of Plan 9.

Yeah, I did not include anything without at least some recent development. AROS and plan9 both got cut for that reason.

I was on the fence about including ReactOS but wound up not including that either.

Re: Bash 5.0 released

#278

Post by charlesdaniels »

aryamaan wrote: post #195
charlesdaniels wrote: post #29

Earlier quoted context omitted.

If you're doing it right, you are solving very different problems with shell vs any other language. Shell is best used as a tool for orchestrating other programs, you should not be implementing your programs in shell. Syscalls, in general, are used in lieu of objects or other abstractions because they more accurate mirror what the underlying hardware is doing. This isn't always the case, some syscalls are maintained…

> you should not be implementing your programs in shell. What should one be using instead in the current scenario? Python, Rust, Golang?

It depends. I don’t think there is a language which is categorically the best. The solution to a given problem may be harder or easier to express in different languages. Some problems are better solved in C, some in Python, ..., and some in Shell.

Re: Bash 5.0 released

#279

Post by charlesdaniels »

PopeDotNinja wrote: post #71
charlesdaniels wrote: post #29

Earlier quoted context omitted.

If you're doing it right, you are solving very different problems with shell vs any other language. Shell is best used as a tool for orchestrating other programs, you should not be implementing your programs in shell. Syscalls, in general, are used in lieu of objects or other abstractions because they more accurate mirror what the underlying hardware is doing. This isn't always the case, some syscalls are maintained…

When I first learned one could write programs in Bash, I got very excited. It didn't take long for that to where off :) My Bash got a lot better though!

I think everyone who become proficient in shell tries to implement something large in it, gets burned, and realizes that it’s a bad idea. I certainly had that experience.

Re: Bash 5.0 released

#280

Post by faho »

h1d wrote: post #133
a012 wrote: post #93

Earlier quoted context omitted.

Some application still requires bash, like wireguard

What's the problem running it on a 10 year old bash?

bash 4 introduced associative arrays (aka dictionaries or hashmaps).

Which, while you can do without, is a nice feature that makes some things easier.

Post reply on HN