Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Safe ways to do things in bash

github.com

Post reply on HN
Print view View original

91–100 of 255 posts

Re: Safe ways to do things in bash

#91

Post by p3llin0r3 »

TheGrassyKnoll wrote: post #88
p3llin0r3 wrote: post #54

Recently I've replaced most of my bash scripting with the python library invoke. It's written by the same people who wrote the python ssh scripting framework fabric. http://www.pyinvoke.org/ Works great!!

I'll have to try that one. I've done a few things with: Python process launching http://amoffat.github.com/sh

I worked with `sh` for a while. I strongly prefer invoke. It handles signal processing and TTY flawlessly.

You can even get it to ssh into remote terminals and open a console and it works.

It's also a CLI builder where you can chain commands together

Re: Safe ways to do things in bash

#92

Post by deskamess »

koolba wrote: post #8

From the article: > Should I use curly braces? Bad: some_command $arg1 $arg2 $arg3 Extra bad (cargo culting unnecessary braces): some_command ${arg1} ${arg2} ${arg3} Correct: some_command "${arg1}" "${arg2}" "${arg3}" Better: some_command "$arg1" "$arg2" "$arg3" > In the "extra bad" and "correct" examples, braces compete with quotes under the limits of tolerable verbosity. > Shellharden will rewrite all these variant…

When I saw that recommendation it made be sad. I love seeing my variable names with a quick glance. Came to the comments mostly to see if anyone had the same preference.

Re: Safe ways to do things in bash

#93

Post by [deleted] »

JauntyHatAngle wrote: post #72
saagarjha wrote: post #14

Earlier quoted context omitted.

> You are source controlling your shell scripts right? My personal heuristic for shell scripts are that if I care enough about them to put them under source control, they shouldn't be a shell script.

My personal experience would disagree, and I feel that is throwing caution to the wind. As any software person knows, you really can't tell what's going to happen to the code/scripts you put out, not committing it to source control is a dangerous game to play. If you have a simple shell script sitting on a server doing some basic task, why would you not have it under source control where it can be viewed by future te…

[deleted]

Re: Safe ways to do things in bash

#94

Post by Hello71 »

kazinator wrote: post #83
koala_man wrote: post #76

Earlier quoted context omitted.

It is subject to wildcard expansion. You can verify this with var="/*"; echo $var

Ooops, you're right! I somehow mixed this up with special contexts. case $var in '*' ) echo asterisk ;; esac But wildcard expansion is suppressed there unconditionally. Same as in assignment context: other=$var.

those both suppress word splitting too.

Re: Safe ways to do things in bash

#95

Post by koolba »

digitalsushi wrote: post #90
freedomben wrote: post #69

I've written a ridiculous amount of shell script in my day, especially when doing "devops" before we had a term like "devops" to describe it. I've fallen in almost every pit bash has. With that background, here is my opinion. 1. This article contains excellent advice and should be starred for later retrieval. 2. Having basic scripting skills will make you a way better programmer. Many times I've done huge refactors a…

Re 6: I am an /extremely/ mediocre developer but I have crafted some real 99th percentile bash skills (within my company, not globally) and I completely self-sustain myself on just that. (You're wondering how many people write bash where I am, and the answer is somewhere between 8 and 15 thousand people). It's funny how many things that seem kind of incredible for a pure bash solution, looking back over the past 21 y…

> It's funny how many things that seem kind of incredible for a pure bash solution, ...

My go to example of “Bash can do whaaat?!” is the source for xip.io. A custom DNS server written in a handful of lines of Bash!

https://github.com/basecamp/xip-pdns/blob/master/bin/xip-pdn...

Re: Safe ways to do things in bash

#96

Post by Hello71 »

floatingatoll wrote: post #60

The advice to double-quote everything is an interesting way to circumvent "detailed knowledge may be required". I wish it noted that you can't quote regular expressions, though: $ cat - > foo #!/bin/bash a="BCD" [[ $a =~ .C. ]] && echo 1 [[ $a =~ ".C." ]] && echo 2 ^D $ bash foo 1 $

this is intentional, since you can store your regular expression in a variable:

    $ a=BCD; b=.C.; [[ $a =~ $b ]]; echo $?; [[ $a =~ "$b" ]]; echo $?
otherwise, interpolating variables in regular expressions as text would require other syntax (more confusing).

also, "cat -" is redundant, use "cat". this behavior is specified by POSIX.

Re: Safe ways to do things in bash

#97

Post by Hello71 »

nerdponx wrote: post #52

Step 1 to write safer shell scripts: use a safer shell. Zsh gives the user much more control, has safer defaults, and is itself quite portable (even if Zsh scripts are not portable to other shells).

unfortunately, zsh is installed on probably about 1% of Linux systems worldwide. maybe it can be installed almost anywhere, but the fact is it isn't, and you might as well use Python or something at that point.

Re: Safe ways to do things in bash

#100

Post by nickpsecurity »

kazinator wrote: post #86
nickpsecurity wrote: post #82

Earlier quoted context omitted.

That makes it a good idea for a compiler target for a better programming language. Not using it, though. ;)

Someone thought it was a good idea to use a portable subset of the shell as a target for a worse programming language: layers of M4 macros. They didn't back away with anything like "not using it though". So now we have GNU Autotools.

At least the person behind that tragedy apologized in the Generation Lost in the Bazaar article's comment section.

https://queue.acm.org/detail.cfm?id=2349257

That one person did something damaging doesn't refute the point, though. Just avoid another M4 situation.

Post reply on HN