Safe ways to do things in bash • Hacker News Board

Re: Safe ways to do things in bash

#81

Post by Hello71 » Tue, May 15, 2018, 1:24 AM UTC

kazinator wrote: post #45

> Quoting inhibits both word splitting and wildcard expansion, for variables and command substitutions. The result of a variable substitution isn't subject to wilcard expansion, whether quoted or not. If your only reason to quote "$foo" is because you think foo expands to a globbing pattern, and no other reason is justified, you can drop the quotes.

what the balls are you talking about?

    $ touch bad; a='*'; echo $a
    bad

I tested with shbot and this is the case in at least original bourne sh, ksh, mksh, dash, bash 1, and bash 4.4.

Re: Safe ways to do things in bash

#82

Post by nickpsecurity » Tue, May 15, 2018, 1:24 AM UTC

LeoPanthera wrote: post #80

Xcelerate wrote: post #78

I always think — when a programming/scripting language requires this much bizarre knowledge just to write basic code that performs basic tasks, perhaps it is time for that language to be retired. I really don't understand why bash still exists. I've switched to fish and am much happier with the change.

Because it is ubiquitous. You can virtually guarantee that bash will be found on any arbitrary unix-like system.

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

Re: Safe ways to do things in bash

#83

Post by kazinator » Tue, May 15, 2018, 1:25 AM UTC

koala_man wrote: post #76

kazinator wrote: post #45

> Quoting inhibits both word splitting and wildcard expansion, for variables and command substitutions. The result of a variable substitution isn't subject to wilcard expansion, whether quoted or not. If your only reason to quote "$foo" is because you think foo expands to a globbing pattern, and no other reason is justified, you can drop the quotes.

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.

Re: Safe ways to do things in bash

#84

Post by kazinator » Tue, May 15, 2018, 1:27 AM UTC

Hello71 wrote: post #81

kazinator wrote: post #45

> Quoting inhibits both word splitting and wildcard expansion, for variables and command substitutions. The result of a variable substitution isn't subject to wilcard expansion, whether quoted or not. If your only reason to quote "$foo" is because you think foo expands to a globbing pattern, and no other reason is justified, you can drop the quotes.

what the balls are you talking about? $ touch bad; a='*'; echo $a bad I tested with shbot and this is the case in at least original bourne sh, ksh, mksh, dash, bash 1, and bash 4.4.

Indeed; see https://news.ycombinator.com/item?id=17070872

I'd erase my hasty comment if I could. I'm just praying it gets downvoted to invisibility now.

Re: Safe ways to do things in bash

#85

Post by grawprog » Tue, May 15, 2018, 1:31 AM UTC

I find these days I avoid bash a much as possible. I find myself using D for things I would normally use shell scripts for. Bash just...I dunno...why? Why was it designed in such a stupid way....?

Re: Safe ways to do things in bash

#86

Post by kazinator » Tue, May 15, 2018, 1:32 AM UTC

nickpsecurity wrote: post #82

LeoPanthera wrote: post #80

Earlier quoted context omitted.

Because it is ubiquitous. You can virtually guarantee that bash will be found on any arbitrary unix-like system.

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.

Re: Safe ways to do things in bash

#87

Post by kazinator » Tue, May 15, 2018, 1:35 AM UTC

Xcelerate wrote: post #78

I always think — when a programming/scripting language requires this much bizarre knowledge just to write basic code that performs basic tasks, perhaps it is time for that language to be retired. I really don't understand why bash still exists. I've switched to fish and am much happier with the change.

The shell is acceptable for configuring the build of a better language. The excuse there hinges around the argument that we don't want to require the user to already have an executable version of that language installed in order to build that language from sources. And we also don't want to require some competing better language X to build our better language Y, because that doesn't look good.

Re: Safe ways to do things in bash

#88

Post by TheGrassyKnoll » Tue, May 15, 2018, 1:36 AM UTC

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

Re: Safe ways to do things in bash

#89

Post by wocram » Tue, May 15, 2018, 1:37 AM UTC

Is this project ready to share?

It's not published to crates.io, and doesn't have a license or Cargo.toml

Re: Safe ways to do things in bash

#90

Post by digitalsushi » Tue, May 15, 2018, 1:39 AM UTC

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 years doing this drivel. This year is the first I had to learn how to export all of the shell's variables and function definitions for a forked clone to run asynchronous background processing of the main thread. Bash! Bash of all things. Probably 10 seconds in any other language, but here is bash kind of hopping alongside. Callbacks, reflective programming, there's always a really awkward way in bash to do what's happening in the popular languages.