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

41–50 of 306 posts

Re: Bash 5.0 released

#41

Post by wlib »

dfc wrote: post #36
wlib wrote: post #22

Earlier quoted context omitted.

That misses my poorly written point. Do you use a separate, awkward tool to call functions you wrote in python? Or do you call the function in python itself? The shell is a useless abstraction that was only necessary in unix because the alternative was c. Now that we have better languages, why not use them to write the OS bottom-up?

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

Re: Bash 5.0 released

#42

Post by cheez »

JeremyBanks wrote: post #5
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.

It can't be done. If you want to write reliable code, and actually notice all of the possible error conditions instead of silently ignoring them, your code needs to get more verbose and complicated than it would be to just use a more capable tool like Python or Node, and it still won't be as reliable. If you have more logic than a couple of string comparisons, Bash is not the right tool for the job.

I just use set -e at the top of the script

Re: Bash 5.0 released

#43

Post by Carpetsmoker »

pstuart wrote: post #37
pornel wrote: post #32

Reminder that 2019 version of macOS ships with 2007 (last GPL2) version of Bash, and will never ship with any newer version. /bin/bash --version GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18) Copyright (C) 2007 Free Software Foundation, Inc. macOS used to be an awesome developer machine with good tools out of the box. Now the built-in tools are just a bootstrap for their own replacement via Homebrew. Lik…

I still don't understand how a gnu binary could taint their OS. They can provide the source on opensource.apple.com. Case closed.

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.

Re: Bash 5.0 released

#44

Post by a012 »

_emacsomancer_ wrote: post #40
pornel wrote: post #32

Reminder that 2019 version of macOS ships with 2007 (last GPL2) version of Bash, and will never ship with any newer version. /bin/bash --version GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18) Copyright (C) 2007 Free Software Foundation, Inc. macOS used to be an awesome developer machine with good tools out of the box. Now the built-in tools are just a bootstrap for their own replacement via Homebrew. Lik…

I assume you can install newer versions of Bash on macOS though? (But it certainly suggests to me that macOS isn't actually the easiest out-of-the-box solution if your workflow includes anything more than web browsing.)

Sure you can install newer version of bash via homebrew then update PATH in your shell profile.

Re: Bash 5.0 released

#45

Post by wlib »

algesten wrote: post #39
wlib wrote: post #22

Earlier quoted context omitted.

That misses my poorly written point. Do you use a separate, awkward tool to call functions you wrote in python? Or do you call the function in python itself? The shell is a useless abstraction that was only necessary in unix because the alternative was c. Now that we have better languages, why not use them to write the OS bottom-up?

The choice of python as your shell would surely be as arbitrary as bash? There is a long history of alternative shells csh, tcsh, zsh, fish, etc. All with various level of abstraction and various amounts of "programming language type constructs" (for lack of a better term). At the end of the day, long arguments have been had over which is the better shell. It's all just personal preference. Hence it can be set in /et…

My point wasn't about python, just an example of how a shell around python, made only for python function calls, would be a useless abstraction.

Re: Bash 5.0 released

#46

Post by AnIdiotOnTheNet »

minitech wrote: post #23
wlib wrote: post #22

Earlier quoted context omitted.

That misses my poorly written point. Do you use a separate, awkward tool to call functions you wrote in python? Or do you call the function in python itself? The shell is a useless abstraction that was only necessary in unix because the alternative was c. Now that we have better languages, why not use them to write the OS bottom-up?

Because writing new OSes is hard and writing new OSes where existing software that people want to use keeps working is even harder.

And thus the tech industry piled abstraction upon abstraction, decade after decade, until finally all software collapsed into a singularity and destroyed the earth. Which, frankly, came as somewhat of a relief to all the people forced to use it.

Re: Bash 5.0 released

#47

Post by _emacsomancer_ »

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…

It's not quite the same thing, but I've been enjoying using eshell (https://www.gnu.org/software/emacs/manual/html_mono/eshell.h...). It has the usual shell interaction, except you can also interleave it with arbitrary elisp. It's not quite the OS, but it allows interaction with any parts of Emacs, which is at least OS-like (and can itself interact with the OS in various ways).

Re: Bash 5.0 released

#49

Post by AnIdiotOnTheNet »

nwatson wrote: post #13
JeremyBanks wrote: post #5

Earlier quoted context omitted.

It can't be done. If you want to write reliable code, and actually notice all of the possible error conditions instead of silently ignoring them, your code needs to get more verbose and complicated than it would be to just use a more capable tool like Python or Node, and it still won't be as reliable. If you have more logic than a couple of string comparisons, Bash is not the right tool for the job.

I recommend Greg's Bash Wiki ... https://mywiki.wooledge.org/BashGuide . See general notes, then at the bottom of the page are many links to additional considerations. Like others say, "bash" is a hard tool to get right (and I'm not saying I do it right either, necessarily, but Greg's Wiki was real helpful!). I'm building a hybrid bash/python3 environment now (something I'll hopefully open-source at some point), and…

Or you just bundle your application and its dependencies into a single folder for each OS and distribute it.

Re: Bash 5.0 released

#50

Post by LukeShu »

dualbus wrote: post #33
mturmon wrote: post #27

Earlier quoted context omitted.

“BASH_ARGV0: a new variable that expands to $0 and sets $0 on assignment.” Changing argv[0] would make utilities like ps show a more descriptive/shorter name, eg in the case of long command paths.

I don't think changing argv[0] in the current process will have any effect in the /proc file system. And to do what you describe, there's `exec -a NAME' already: $ (exec -a NOT-BASH bash -c 'echo $0; ps -p $BASHPID -f') NOT-BASH UID PID PPID C STIME TTY TIME CMD dualbus 18210 2549 0 19:30 pts/1 00:00:00 NOT-BASH -c echo $0; ps -p $BASHPID -f

> I don't think changing argv[0] in the current process will have any effect in the /proc file system.

Yes it does. This is a standard trick for changing the process name at runtime, several daemons do this to change the process name of child processes created by fork() that aren't separate executable. For instance, OpenSSH's sshd sets the child-process for a session to "sshd: USERNAME [priv]".

`exec -a` lets you set argv[0] through an execve() call, but many times you want to set it without exec'ing a new program.

Post reply on HN