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

151–160 of 306 posts

Re: Bash 5.0 released

#151

Post by viraptor »

adrianN wrote: post #105
viraptor wrote: post #81

Earlier quoted context omitted.

> if you have a script iterating over 10k files That's probably a good sign you should advance from shell. If the script is trivial, it's going to be trivial in python / ruby / go / crystal / ... as well. If it's not trivial, that's another reason to move.

I agree that as scripts get more complex, you should migrate from bash. But the number of files a script touches says almost nothing about its complexity.

Wasn't saying otherwise. One reason is complexity. Another is performance.

Re: Bash 5.0 released

#152

Post by laumars »

wlib wrote: post #41
dfc wrote: post #36

Earlier 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

That’s great for developers who are competent in that paradigm but what about hobbyists or sysadmins who have little interest in software development?

I’m not saying POSIX shells are without fault but they weren’t just created because C is too low level; they were created because people used a terminal who weren’t always techies so Bell Labs created a language which anyone could easily write simple programs with. Granted that need has dissipated a little but your solution of having one language to rule them all creates more problems than it solves (really the only problem it solves is OCD for a few LISP enthusiasts).

The reason there are so many different programming languages isn’t just an element of NIH; some languages do genuinely handle some use cases better than some other languages. Plus there is always going to be an element of user preference. So your idea of a perfect system would be hell for a great many other people - myself included (and I do generally enjoy functional programming).

Re: Bash 5.0 released

#153

Post by IshKebab »

nothrabannosir wrote: post #149
_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…

Please no. The parallel universe Me where I didn't happen to read this random thread would never know, consequently never expect random variables to do that. And curse you forever if I found out while banging my head debugging some buggy script.

Yeah what's wrong with functions? Clearly the Bash developers are continuing their tradition of obeying the principle of most surprise.

Re: Bash 5.0 released

#154

Post by nothrabannosir »

wlib wrote: post #11

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

(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 constantly wrap your strings in quotes, calling subprocess modules, exec, painstaking handing of streams, etc.

Then you start looking for a language that has better syntax for calling external programs.. hmm...

Bash. Or zsh, or ksh, etc. These languages excel at it. But that's all they are: programming languages that happen to be super easy to use when it comes to starting external programs.

This is why it makes little sense to bind them to the OS. As far as the OS is concerned: there is no Bash. Just like there is no Python. There is just syscalls.

Re: Bash 5.0 released

#155

Post by stock_toaster »

ajross wrote: post #60
Carpetsmoker wrote: post #43

Earlier quoted context omitted.

The problem is that GPL3 has more restrictions than just "publish the code". That's why projects such as FreeBSD, OpenBSD, etc. also won't include GPL3 code, as including GPL3 code would restrict what you can and can't do with the entire system. I assume that Apple's reasoning is similar.

Can you name them? It's not exactly snark. My experience is that almost everyone with strong GPLv3 opinions turns out not to actually object to the terms themselves when discussed in isolation. To head off: it's not the patent grant. Apache 2 has a very similar patent grant and everyone is fine with it.

> Apache 2 has a very similar patent grant and everyone is fine with it.

OpenBSD apparently isn't fine with it, fwiw.

> The original Apache license was similar to the Berkeley license, but source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD.

> -- ref: https://www.openbsd.org/policy.html

Re: Bash 5.0 released

#156

Post by sbuk »

ajross wrote: post #102
int_19h wrote: post #95

Earlier quoted context omitted.

A lot, because it's hard to derive meaningful conclusions from something that's used so relatively little precisely because of licensing concerns. Anyway, with v2, the concerns were more vague - you'd have to accidentally link something GPLv2. With v3, even just shipping the binary signed with a private key on a platform that requires said key to load it, is enough to potentially force disclosure of that key (and tha…

Right, so the risk can't be quantified and the whole thing is just isomorphic "because I don't like it". Which was as true then as it is now. It's not about license terms, it's about what amounts to politics.

> It's not about license terms, it's about what amounts to politics.

Which is exactly what the GPL is! Especially v3.

Re: Bash 5.0 released

#157

Post by emersion »

flatline wrote: post #54
fxfan wrote: post #31

As someone who lives in zsh and bash for interactive usage- I want to say- please do not write scripts in bash or zsh. Use powershell- its an amazingly well designed scripting language. Also- there is ammonite. Written for scripting.

Powershell has been around for quite a while now, but only recently could you rely on it being installed on Windows systems, let alone be available on Linux. Maybe in another decade, but if you are targeting Unix-like systems bash is probably still your safest bet for portable, interpreted code. Python2 is a close second.

POSIX sh is your safest bet for portable, interpreted code.

Re: Bash 5.0 released

#158

Post by reacweb »

darkpuma wrote: post #138
gnulinux wrote: post #121

Earlier quoted context omitted.

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…

#!/bin/sh Leave bash out of it tbh. In practice that will often end up being bash, but sometimes it won't be an in those cases you'll have yourself covered. Test it with busybox's sh or with dash, just to make sure.

I disagree. I have seen developpers trying to write posix conformant scripts but only testing on bash on redhat. When deploying on ubuntu, /bin/sh was dash and the script did not work. I think people shall use #!/bin/bash until their script has been really tested using dash or busybox. If they do not want to do this additional test work, they should never use #!/bin/sh

Re: Bash 5.0 released

#159

Post by j16sdiz »

tspiteri wrote: post #147
int_19h wrote: post #95

Earlier quoted context omitted.

A lot, because it's hard to derive meaningful conclusions from something that's used so relatively little precisely because of licensing concerns. Anyway, with v2, the concerns were more vague - you'd have to accidentally link something GPLv2. With v3, even just shipping the binary signed with a private key on a platform that requires said key to load it, is enough to potentially force disclosure of that key (and tha…

The outcome of violating the GPL is license termination: you cannot distribute it any more. I don't think there has ever been a case of enforced further distribution or disclosure.

Termination means recall / reimage all device on store shelf and maybe compensation for those distrubited without license.

Re: Bash 5.0 released

#160

Post by xorcist »

giancarlostoro wrote: post #2

Any recommended reading for Bash? I'm somewhat new to it and it's interesting ways of getting things done. I've used it minimally in the past, but have found myself writing a 100> LOC script, which I can't help but feel I'm likely over-complicating certain bits and pieces.

There used to be this great resource called Linux Documentation Project. It's not as active as it used to be but it produced some really book-quality documents, including the Advanced Bash Scripting Guide at https://www.tldp.org/LDP/abs/html/ .

Read it! It's great. But know that a lot of bash scripting isn't really in bash, it's really required to be proficient with grep, sed, cut, dc and a few other text processing utilities. Learn those! Then are are a few other tricks to be mindful of: be mindful of spaces (wrap your variable substitution in double quotes, mostly), be mindful of sub-shells (piping to something that sets variables can be problematic), and a few other things that can really only be learned by reading good code.

But it's also good to know when you shouldn't venture further. My rule of thumb is when I'm using arrays or hash maps, then it's a good idea to move to another language. That's probably Python nowaways. A lot of people use tons of awk or perl snippets inside their bash scripts, that can also be a sign that it's time to move the whole script over.

Post reply on HN