Earlier quoted context omitted.
#!/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
Bash 5.0 released
191–200 of 306 posts
Re: Bash 5.0 released
#192Re: Bash 5.0 released
#193Earlier quoted context omitted.
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.
About termination, what you mention is kind of stopping further violation of the terms and maybe compensation for the past violations. What I wanted to mention (but wasn't at all clear about) is that after termination, you cannot even distribute if you intend to abide by the terms unless you are forgiven by the copyright holder. (In the case of the GPL version 3 there is some grace period during which for the first violation, if you abide within that period, you are explicitly permitted to resume distribution under the license terms.)
Re: Bash 5.0 released
#194As 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.
program | tee filename.txt &
It's also too verbose and needs too much shift for me to comfortably use as a shell. So why not just use a 'real' language if I'm going to write a script?
Re: Bash 5.0 released
#195Why 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'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…
What should one be using instead in the current scenario?
Python, Rust, Golang?
Re: Bash 5.0 released
#196Earlier 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?
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.
Re: Bash 5.0 released
#197With 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…
Re: Bash 5.0 released
#198Earlier quoted context omitted.
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
#199Why 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 5.0 released
#200With 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…
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.
I'm reminded of the Jargon file that says "Syntactic sugar causes cancer of the semicolon."