Live data from Hacker News

Pure Sh Bible

github.com

91–100 of 138 posts

Re: Pure Sh Bible

#91

Earlier quoted context omitted.

Shell is full of ridiculous footguns though. It's like saying if the store is only 60m away (across an Indiana Jones-tier trap gauntlet) then just walk there. Remember that time bumblebee accidentally deleted everyone's /usr? Or that time steam deleted everyone's homedir? Both because of the easiest to avoid bash footguns - spaces and empty variables. My hard and fast rule that I've never regretted is - if you use a…

Have you not used Python or Perl much? Because both are full of footguns. And I don't see any advantage to for loops in a HLL. These are identical: for i in `seq 1 10` ; do echo i $i done for i in range(1,10): print("i %i\n") You might find problems with the shell code, and I'll find problems with the Python. But both will print 1 to 10.

Personally I've found Python to have significantly fewer foot-guns than bash.

The biggest reason why I don't use it all of the time is that calling / piping commands takes a lot more typing, so it's easier to use bash for very simple shell scripts. And while there are libraries that simplify shell scripting, that adds external dependencies to your scripts.

> for i in range(1,10): > print("i %i\n")

This outputs "i %i\n\n" 9 times.

Re: Pure Sh Bible

#92

Some nice stuff, but also some stuff, where things get easier if you just switch to a language with less caveats (like Python). My rule of thumb is to use Bash to write simple scripts, if they fit on the command line and have just one level of loop or if-else (lines can get very long, though ...). However for more complicated stuff I use the alternative programs (find, sed, awk, ...), as they behave more predictable.…

  > where things get easier if you just switch to a language with less caveats (like Python).
For general, non-domain specific things, it gets IMO easier by two main reasons 1) obviously when using tools where one has more experience with, but 2) also when the tool is more widely available, and POSIX shell is probably one of the most (by default) available interpreters with a somewhat human-friendly input mode there is. I know if I write a script or some functions in POSIX shell I can copy it and run it wherever I want (besides Windows, but don't really know anybody close to me that still uses that, especially in a server environment). Sure, if everywhere you want to run it python/perl/... is just available, or simple to install (i.e., any modern Linux or *BSD distro), then the second point hasn't that much weight anymore besides maybe for minimal Alpine Linux CTs (
  >  I mean having a '.' in the string does make it a non-integer, but what about other floats like 2e3?
They use the printf "%f" float format conversion so `printf "%f" 2e3` will work just fine, whereas using something that definitively is not a float makes printf exit with an error code as it fails to format the value as float, failing this check.

Re: Pure Sh Bible

#93

Earlier quoted context omitted.

Shell syntax isn't "wacky", it's extremely error prone. Using shell script instead of a sane language is like opening beer with your teeth because you can't be bothered to get a bottle opener.

Oh, right, because it's not easy to cause errors in Python.

Python stops on errors.

Bash may or may not. It depends on how your script was called. If your script is sourced you need to remember to set and restore the flags.

In bash your data can accidentally become code. "rm $fn" usually deletes one file, but it might one day delete a few (spaces), or wildcard expansion makes it delete many. With Python, calling the function to delete one file will always delete one file. Your function will never run with a "continue on errors" mode.

Re: Pure Sh Bible

#94

Earlier quoted context omitted.

Using a more advanced language just because you find shell syntax to be wacky is like using a car to get groceries because you find panniers or a backpack to be wacky. It's the use case that matters; if you're 60 meters from the store, just use your bike, or walk. There are plenty of cases in which Perl or Python will make things much more complicated than 5 lines of spooky-looking shell script. Sometimes a little my…

Shell is full of ridiculous footguns though. It's like saying if the store is only 60m away (across an Indiana Jones-tier trap gauntlet) then just walk there. Remember that time bumblebee accidentally deleted everyone's /usr? Or that time steam deleted everyone's homedir? Both because of the easiest to avoid bash footguns - spaces and empty variables. My hard and fast rule that I've never regretted is - if you use a…

> Remember that time bumblebee accidentally deleted everyone's /usr? Or that time steam deleted everyone's homedir? Both because of the easiest to avoid bash footguns - spaces and empty variables.

https://www-uxsup.csx.cam.ac.uk/misc/horror.txt

Your exanples were bugs which were not caught during development because "testing is hard and expensive" and "if it compiles, ship it".

Re: Pure Sh Bible

#95

Earlier quoted context omitted.

Using a more advanced language just because you find shell syntax to be wacky is like using a car to get groceries because you find panniers or a backpack to be wacky. It's the use case that matters; if you're 60 meters from the store, just use your bike, or walk. There are plenty of cases in which Perl or Python will make things much more complicated than 5 lines of spooky-looking shell script. Sometimes a little my…

Shell is full of ridiculous footguns though. It's like saying if the store is only 60m away (across an Indiana Jones-tier trap gauntlet) then just walk there. Remember that time bumblebee accidentally deleted everyone's /usr? Or that time steam deleted everyone's homedir? Both because of the easiest to avoid bash footguns - spaces and empty variables. My hard and fast rule that I've never regretted is - if you use a…

The shell is not meant to implement the X Window System in it. The shell is a command interpreter.

If you want to do more advanced things there is always the right tool for the job although with an increased attack surface.

Re: Pure Sh Bible

#96
post #94

Earlier quoted context omitted.

Shell is full of ridiculous footguns though. It's like saying if the store is only 60m away (across an Indiana Jones-tier trap gauntlet) then just walk there. Remember that time bumblebee accidentally deleted everyone's /usr? Or that time steam deleted everyone's homedir? Both because of the easiest to avoid bash footguns - spaces and empty variables. My hard and fast rule that I've never regretted is - if you use a…

> Remember that time bumblebee accidentally deleted everyone's /usr? Or that time steam deleted everyone's homedir? Both because of the easiest to avoid bash footguns - spaces and empty variables. https://www-uxsup.csx.cam.ac.uk/misc/horror.txt Your exanples were bugs which were not caught during development because "testing is hard and expensive" and "if it compiles, ship it".

And yet Rust gains traction over C. "Best practice" can't fix a dangerous tool.

Re: Pure Sh Bible

#97
POSIX shell scripting is just broken. Don't get me wrong. I love doing it, but from a language design point it is abysmal.

Just this week I tried to write a script to apply a custom function to a list of files. But the amount of time you spend just to make sure it works with special cases like spaces or new line characters in file names is not healthy. After all, it is probably one of the most standard scenarios.

First, I thought I would use 'find -execdir' or 'find | xargs', but neither supports shell functions. So I went on to take the 'while read' road, just to learn, that POSIX 'read', does not support all options you would need to make that work with all special cases.

Re: Pure Sh Bible

#98

Some nice stuff, but also some stuff, where things get easier if you just switch to a language with less caveats (like Python). My rule of thumb is to use Bash to write simple scripts, if they fit on the command line and have just one level of loop or if-else (lines can get very long, though ...). However for more complicated stuff I use the alternative programs (find, sed, awk, ...), as they behave more predictable.…

> where things get easier if you just switch to a language with less caveats (like Python). For general, non-domain specific things, it gets IMO easier by two main reasons 1) obviously when using tools where one has more experience with, but 2) also when the tool is more widely available, and POSIX shell is probably one of the most (by default) available interpreters with a somewhat human-friendly input mode there is…

> They use the printf "%f" float format conversion so `printf "%f" 2e3` will work just fine, whereas using something that definitively is not a float makes printf exit with an error code as it fails to format the value as float, failing this check.

You are of course correct (sorry to sound like a language model), I missed the printf.

Re: Pure Sh Bible

#99
post #14

Problems with this advice: ::looping over a file The "loop over the contents of a file" entry does not protect stdin. Use an alternate descriptor. while read -r line Particularly problematic is ssh, that will pass $line to any remote command that is able to consume it. The looped commands will receive stdin of the loop when an alternate descriptor is used. I use 9 by habit after reading the flock manual page many yea…

You might also want to clear IFS if you don't want to trim leading/trailing whitespace (taken from https://mywiki.wooledge.org/BashFAQ/001):

  while IFS= read -r line  ignoredfile
    printf '%s\n' "$line"
  done 9
("cat" is used as an example of a command eating stdin)
Post reply on HN