191–200 of 281 posts
Earlier quoted context omitted.
As a bash casual, these suggestions are a reminder of why I avoid using bash when I can. That's a whole armory of footguns right there.
Embrace bash. Use it as your login shell. Use it as your scripting language. Double check your scripts with shellcheck.
Earlier quoted context omitted.
> "So no, I don’t want my shell to also have to talk..." What's the point of the shell, if not to manage your databases, your REST APIs, files, and mail? Is it something you use for playing games on, or just for fun? > designed to do one thing well. Eeexcept that this is not actually true in practice, because the abstraction was set at a level that's too low . Shoving everything into a character (or byte) stream turn…
> What's the point of the shell, if not to manage your databases, your REST APIs, files, and mail? Is it something you use for playing games on, or just for fun? It's for communicating with the operating system, launching commands and viewing their output. And some scripting for repetitive workflows. If I'd want a full programming environment, I'd take a Lisp machine or Smalltalk (a programmable programming environme…
Earlier quoted context omitted.
You mean import os os.rename(“src.txt”, “dest.txt”) ?
Yes. And it is only downhill from there. Now, show us `mycommand | sed 's/ugly/beautiful/g' | awk -F: '{print $2,$4}' 1> something.report 2> err.log` in Python.
Like.
myvar = `mycommand | sed 's/ugly/beautiful/g' | awk -F: '{print $2,$4}' 1> something.report 2> err.log`
This reads like what I've named as "consultantware" which is a type of software developed by security consultants who are eager to write helpful utilities but have no idea about the standards for how command line software behaves on Linux. It ticks so many boxes: * Printing non-output information to stdout (usage information is not normal program output, use stderr instead) * Using copious amounts of colours everywhe…
I think it’s pretty good hygiene to set pipefail in the beginning of every script, even if you end up not using any pipes. And at that point is it that important to go back and remove it only to then have to remember that you removed it once you add a pipe?
Earlier quoted context omitted.
Embrace bash. Use it as your login shell. Use it as your scripting language. Double check your scripts with shellcheck.
POSIX gang disapproves
What good is trading away the benefits of bash extensions just to run the script on a homogeneous cluster anyways?
The only remotely relevant alternative operating systems all have the ability to install a modern distribution of bash. Leave POSIX shell in the 1980s where it belongs.
Earlier quoted context omitted.
Yes. And it is only downhill from there. Now, show us `mycommand | sed 's/ugly/beautiful/g' | awk -F: '{print $2,$4}' 1> something.report 2> err.log` in Python.
In ruby you can just call out to the shell with backticks. Like. myvar = `mycommand | sed 's/ugly/beautiful/g' | awk -F: '{print $2,$4}' 1> something.report 2> err.log` That way, if something is easier in Ruby you do it in ruby, if something is easier in shell, you can just pull its output into a variable.. I avoid 99% of shell scripting this way.
But if all I need to do is generate the report I proposed...why would I embed that in a Ruby script (or a Python script, or a Perl script, etc.) when I could just use a bash script?
Earlier quoted context omitted.
> Except that'll pick up an old (2006!) (unsupported, I'm guessing) version of bash (3.2.57) on my macbook rather than the useful version (5.2.26) installed by homebrew. Could you change that by amending your $PATH so that you're preferred version is chosen ahead of the default?
> Could you change that by amending your $PATH I think the `#!/bin/bash` will always invoke that direct file without searching your $PATH. People say you can do `#!bash` to do a $PATH search but I've just tried that on macOS 15 and an Arch box running a 6.10.3 kernel and neither worked.
That's why env is generally preferred as it finds the appropriate bash for the system.