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

Test your square brackets

fluca1978.github.io

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Test your square brackets

#61

Post by jcims »

jez wrote: post #57
jcims wrote: post #21

Reminds me of my rather memorable introduction to special characters invoking functions, seeing this dastardly little quip in the email signature of someone in a mailing list (circa '95 or so). :(){:|:&};: My curiosity piqued, I pasted it into the shell on my terminal in a pure example of FAFO. The poor little Sparc 5 I was using ground to a halt over the course of about ten seconds. The reboot was as hard as the les…

Something I never understood about this: is the pipe necessary, or just to have another symbol contributing to the mayhem? :(){:&;:};: This is the same number of characters but doesn’t use a pipe, and I was never able to figure out why it seems so universally to use a pipe.

One way to find out!

Re: Test your square brackets

#62

Post by JuniperMesos »

I don't like bash, and this kind of esoteric, hard-to-remember syntax is a big reason why. Software developers and computer users should want their shell to be easy to use and reason about, just as they reasonably want this from their general-purpose software development languages.

bash is a UNIX legacy tool from the 80s that lingers on in software written today because it's part of the POSIX standard (well, sh, which is close enough), and because generations of developers on UNIX-like systems can be assumed to be familiar with it. I don't think this is a good thing, and I would like to see active efforts to replace the use of bash with better, more-modern scripting languages that provide an easier-to-understand more-reliable experience for users.

Re: Test your square brackets

#63

Post by PhilipRoman »

ndsipa_pomu wrote: post #13
PhilipRoman wrote: post #8

Earlier quoted context omitted.

[[...]] is non-portable and has an extremely quirky corner case with variable expansion in arithmetic contexts, what's not to love?

I'm intrigued - any info on that? I personally use ((...)) for arithmetic tests and [[...]] for all other tests as I just target new versions of BASH and don't care much about POSIX compatibility.

This is completely safe: [ "${payload}" -eq 42 ]

This can evaluate arbitrary code: [[ "${payload}" -eq 42 ]]

Here is one example of a malicious payload:

  payload='a[$(touch /tmp/pwned)]'

Re: Test your square brackets

#64

Post by ndsipa_pomu »

PhilipRoman wrote: post #63
ndsipa_pomu wrote: post #13

Earlier quoted context omitted.

I'm intrigued - any info on that? I personally use ((...)) for arithmetic tests and [[...]] for all other tests as I just target new versions of BASH and don't care much about POSIX compatibility.

This is completely safe: [ "${payload}" -eq 42 ] This can evaluate arbitrary code: [[ "${payload}" -eq 42 ]] Here is one example of a malicious payload: payload='a[$(touch /tmp/pwned)]'

Thanks.

Now I need to figure out whether (( payload == 42 )) is safe.

Re: Test your square brackets

#65

Post by Normal_gaussian »

Normal_gaussian wrote: post #43
ogogmad wrote: post #40

Earlier quoted context omitted.

> The reboot was as hard as the lesson. I'm confused. What happened on reboot?

A hard reboot is where the power goes all the way off, a soft reboot is where it doesn't. A fork bomb makes it very hard / impossible to trigger a soft reboot, forcing you to do a hard reboot. As an extra sting, a hard reboot can be damaging if the software and hardware is not correctly handling power interruption, which was much more likely in the 90's.

To clarify a little - a hard reboot in this case is not performed by issuing a shutdown power off command, which is safe, but by pulling the plug from the wall (the worst shutdown) or holding the switch down (quite bad).

Re: Test your square brackets

#66

Post by duskdozer »

stabbles wrote: post #35
duskdozer wrote: post #9

Earlier quoted context omitted.

You mean shellcheck will detect when single brackets won't be enough? I've also just defaulted to double because I never really looked into it

Yeah, if you set the shebang `#!/bin/sh` (which is portable), shellcheck will complain about double brackets. It also helps you do quoting correctly when using single brackets.

I see. I've always just used `#!/usr/env/bin bash`. I wonder if there's a directive to hint at incompatibilities without changing it? I'll have to see.

And this isn't meant snarkily - why should I care if my scripts are portable? I've worked on a number of different devices and types but have seemingly always had access to bash.

Re: Test your square brackets

#67

Post by ndsipa_pomu »

ndsipa_pomu wrote: post #64
PhilipRoman wrote: post #63

Earlier quoted context omitted.

This is completely safe: [ "${payload}" -eq 42 ] This can evaluate arbitrary code: [[ "${payload}" -eq 42 ]] Here is one example of a malicious payload: payload='a[$(touch /tmp/pwned)]'

Thanks. Now I need to figure out whether (( payload == 42 )) is safe.

It appears not.

Re: Test your square brackets

#68

Post by Ferret7446 »

jez wrote: post #57
jcims wrote: post #21

Reminds me of my rather memorable introduction to special characters invoking functions, seeing this dastardly little quip in the email signature of someone in a mailing list (circa '95 or so). :(){:|:&};: My curiosity piqued, I pasted it into the shell on my terminal in a pure example of FAFO. The poor little Sparc 5 I was using ground to a halt over the course of about ten seconds. The reboot was as hard as the les…

Something I never understood about this: is the pipe necessary, or just to have another symbol contributing to the mayhem? :(){:&;:};: This is the same number of characters but doesn’t use a pipe, and I was never able to figure out why it seems so universally to use a pipe.

Having a pipe will also eat up your system's file table, so it's potentially more efficient.
Post reply on HN