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

281–290 of 306 posts

Re: Bash 5.0 released

#281

Post by nivenhuh »

wicket wrote: post #226

Seeing this release makes me cringe. I've used Bash as an interactive shell for decades but really I'm sick and tired of it. As a scripting language, I loathe it and really don't understand its purpose. I always write shell scripts in POSIX shell for portability reasons. Most of the time I don't need to use any of Bash's features. In cases where advanced features are needed and portability is not a concern, there are…

I think tcsh might hit your requirements.

(Personally, I use zsh, but it's much more heavy than tcsh.)

Re: Bash 5.0 released

#282

Post by pwg »

e12e wrote: post #270
pwg wrote: post #201

Earlier quoted context omitted.

True, but if you are iterating over 10k files and removing them, then a find|xargs pipe with xargs feeding rm the maximum number of parameters the kernel allows per fork will likely be faster than a bash interpreter loop, even with a bash builtin rm.

You think find|xargs would be faster than (gnu) find -delete?

No, my comment was "will likely be faster than a bash interpreter loop". The key phrase is "bash interpreter loop".

I was not comparing find|xargs to find -delete.

Re: Bash 5.0 released

#283

Post by int_19h »

gnulinux wrote: post #121
int_19h wrote: post #118

Earlier quoted context omitted.

> I can write my code in bash and forget about it. In practice, this approach often results in code that works only on Linux, or on Linux and macOS. I especially hate it when people shove #!/bin/bash as a shebang, and doubly so when it's in scripts that are a part of some npm package. (On BSDs, Bash is not installed out of the box, and when it is installed, it's not in /bin, since it's not in the base system.) Still,…

I think this is a good point but, there is an implicit but well known notion that if you write bash and care about platform coverage, you just write bourne shell. I didn't explicitly write it, but I assumed I would write bourne shell, and whatever shell in random Unix will be able to handle it as well as bash in linux||macOS. As a python lover, I simply can't find one reason to use any other scripting language other…

> there is an implicit but well known notion

I wish it was well known. There are many people who don't even realize that Bash and Bourne shell are two different things. From there they assume that if their system runs it correctly, then it's portable.

Re: Bash 5.0 released

#284

Post by int_19h »

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?

Because one of the scenarios we were talking about is interactive use - i.e. command prompt. Current directory (and other implicit state like that) is convenient there, and removing it would make it that much harder to use.

Re: Bash 5.0 released

#285

Post by int_19h »

Carpetsmoker wrote: post #120
int_19h wrote: post #92

Earlier quoted context omitted.

On FreeBSD, as I recall, they don't want any GPL'd code in the base system, simply because the ideological goal is to have everything under BSDL. It's not that it affects other bits of the system though.

Yeh, GPL2 is also considered less than ideal, and replacing GPl2 code has been a low-key long-term goal. GPL2 is still considered acceptable though, whereas GPL3 is outright barred.

Is there any GPL code remaining in the base at this point? I thought it was all gone once they replaced gcc with Clang.

Re: Bash 5.0 released

#286

Post by offmycloud »

ltc5505 wrote: post #255
offmycloud wrote: post #164

It's sad that lists.gnu.org is running obsolete TLS 1.0 crypto with weak 1024-bit DH. Either upgrade to TLS 1.2 with reasonable cipher suites, or just go back to plain HTTP.

Since I'm clueless on the subject, can I ask how you determined that information and what resource I could use to become better informed?

A good first step is disabling SSL 3.x and TLS 1.0 in your daily browser. I would also recommend the excellent Qualys SSL Server Test: https://www.ssllabs.com/ssltest/

Re: Bash 5.0 released

#287

Post by Risord »

adwn wrote: post #276
Risord wrote: post #269

Earlier quoted context omitted.

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…

You can still build compatibility layer on top of immutable FS. Like being mutable from program(s) perspective while being able to control how these changes are capsulated from rest of the system. You could, for example, see what your

> any OS, application, library, filesystem, device driver, database, nearly everything related to computing at all

-is trying to actually do to your files and operation like reverting changes is trivial. Sure it's not performance optimal and effects what kind of software is ideal to work within such a system. It's just a different approach with different trade-offs.

Anyway if I one day want to build new OS it's for trying different interesting approaches and not yet another 'successful any-OS'.

Re: Bash 5.0 released

#288

Post by Risord »

int_19h wrote: post #284
Risord wrote: post #269

Earlier quoted context omitted.

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?

Because one of the scenarios we were talking about is interactive use - i.e. command prompt. Current directory (and other implicit state like that) is convenient there, and removing it would make it that much harder to use.

If your workflow is like: 1. Manipulate current directory 2. Run some program 3. Manipulate current directory again 4. Run yet another program...

You can actually consider current directory as immutable already.

It became "badly mutable" for example if you manipulate the current directory and this change is observable from a program point of view which is already running. Would that be really useful?

To clarify I am not trying to say that absolutely everything should be immutable but it's fun thought experiment how far you can go.

Re: Bash 5.0 released

#289

Post by flukus »

hawski wrote: post #162
flukus wrote: post #140

Earlier quoted context omitted.

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).

Wouldn't "cat $today" result with "cat: No such file or directory: 2019-01-08"? Did you mean echo instead of cat?

My real life use case for these dynamic variables would be more like "cat/vim/cp $log" to get today's log file which would expand to something like /somedir/logs/201901/09/product.log. Handy when you have a large matrix of products/environments.

Re: Bash 5.0 released

#290

Post by techntoke »

Risord wrote: post #287
adwn wrote: post #276

Earlier quoted context omitted.

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

You can still build compatibility layer on top of immutable FS. Like being mutable from program(s) perspective while being able to control how these changes are capsulated from rest of the system. You could, for example, see what your > any OS, application, library, filesystem, device driver, database, nearly everything related to computing at all -is trying to actually do to your files and operation like reverting c…

RIP Terry Davis
Post reply on HN