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

Show HN: Rb – Turns Ruby into a command line utility

github.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Show HN: Rb – Turns Ruby into a command line utility

#61

Post by KeyboardFire »

bovermyer wrote: post #50
perlperson wrote: post #25

$ docker ps | rb drop 1 | rb -l split[1] $ docker ps | perl -anE 'say $F[1] if $.>1' perl solved this problem a long time ago, people

Except that in your example, the first line is coherent English, and the second line is just... well... code.

Personally, when I write shell commands, they tend to be write-only code, because the shell isn't really suitable for anything more complex. So it's easier to think in code than it is to add the extra step of translating to English if it's something nobody's gonna see again anyway.

Re: Show HN: Rb – Turns Ruby into a command line utility

#62

Post by KeyboardFire »

It makes me a little uncomfortable that they're using curl|bash for something as simple as "put this 10-line script somewhere in your $PATH," especially when the script involves sudo (to move into /usr/local/bin). Sure, it's easy to inspect the script and see that it's not doing anything malicious, but it makes install processes like this, where it'd be incredibly easy to, seem normal.

Re: Show HN: Rb – Turns Ruby into a command line utility

#63

Post by bdcravens »

KeyboardFire wrote: post #62

It makes me a little uncomfortable that they're using curl|bash for something as simple as "put this 10-line script somewhere in your $PATH," especially when the script involves sudo (to move into /usr/local/bin). Sure, it's easy to inspect the script and see that it's not doing anything malicious, but it makes install processes like this, where it'd be incredibly easy to, seem normal.

I didn't even see that. I followed the directions in the top section ("Clone this repo and copy the rb file to somewhere in your path (or just copy and paste the above).") (I did have to chmod +x)

That said, brew install foo is a normal part of many development workflows, which essentially just curls a file from someone else's git repo.

Re: Show HN: Rb – Turns Ruby into a command line utility

#64

Post by Ajedi32 »

KeyboardFire wrote: post #62

It makes me a little uncomfortable that they're using curl|bash for something as simple as "put this 10-line script somewhere in your $PATH," especially when the script involves sudo (to move into /usr/local/bin). Sure, it's easy to inspect the script and see that it's not doing anything malicious, but it makes install processes like this, where it'd be incredibly easy to, seem normal.

Yeah, and it's not even getting the code from an official source; it's coming from a random bit.ly link [created by a contributor][1].

I've [submitted a PR][2] to inline the install script in the README.

[1]: https://github.com/thisredone/rb/pull/5

[2]: https://github.com/thisredone/rb/pull/8

Re: Show HN: Rb – Turns Ruby into a command line utility

#65

Post by mpg515 »

KeyboardFire wrote: post #62

It makes me a little uncomfortable that they're using curl|bash for something as simple as "put this 10-line script somewhere in your $PATH," especially when the script involves sudo (to move into /usr/local/bin). Sure, it's easy to inspect the script and see that it's not doing anything malicious, but it makes install processes like this, where it'd be incredibly easy to, seem normal.

It's such a common pattern too. I can't believe people are still doing this and it's generally acceptable.

Re: Show HN: Rb – Turns Ruby into a command line utility

#66

Post by kenbellows »

mpg515 wrote: post #65
KeyboardFire wrote: post #62

It makes me a little uncomfortable that they're using curl|bash for something as simple as "put this 10-line script somewhere in your $PATH," especially when the script involves sudo (to move into /usr/local/bin). Sure, it's easy to inspect the script and see that it's not doing anything malicious, but it makes install processes like this, where it'd be incredibly easy to, seem normal.

It's such a common pattern too. I can't believe people are still doing this and it's generally acceptable.

I mean, if you think about it, any time you run any installer, whether via brew install, apt-get install, or an .exe or .msi, you're effectively running someone else's unknown code on your system, often as a superuser (e.g. with sudo apt-get install). Is there a significant difference here? At least in this case you could potentially download the shell file and read it before you run it, unlike with a binary executable.

Am I way off base here?

Re: Show HN: Rb – Turns Ruby into a command line utility

#67

Post by kompromat »

kenbellows wrote: post #66
mpg515 wrote: post #65

Earlier quoted context omitted.

It's such a common pattern too. I can't believe people are still doing this and it's generally acceptable.

I mean, if you think about it, any time you run any installer, whether via brew install, apt-get install, or an .exe or .msi, you're effectively running someone else's unknown code on your system, often as a superuser (e.g. with sudo apt-get install). Is there a significant difference here? At least in this case you could potentially download the shell file and read it before you run it, unlike with a binary executab…

Some context on why curl pipe bash is a bad idea: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Most recent discussion: https://news.ycombinator.com/item?id=17636032

Re: Show HN: Rb – Turns Ruby into a command line utility

#68

Post by ashelmire »

ricardobeat wrote: post #42
star-techate wrote: post #13

Earlier quoted context omitted.

echo hello world | ruby -pe '$_.capitalize!' printf 'hello\nworld\nhello\n' | ruby -le 'puts STDIN.to_a.uniq ps | ruby -lane 'BEGIN { b = 0 }; b += $F[0].to_i; END { print "sum of PIDs: #{b}" } select whatever column you want, to sum up. Really what Ruby needs is a flag that adds some capabilities to NilClass, so that these BEGIN blocks aren't needed.

If this was an attempt at showing this tool is unnecessary, you just did the opposite. Each of your examples use different flags, inputs and print methods. The last is particularly good at proving the point!

Each of those examples is doing different things. This rb script locks you into two of the options.

Re: Show HN: Rb – Turns Ruby into a command line utility

#69

Post by redka »

Ajedi32 wrote: post #64
KeyboardFire wrote: post #62

It makes me a little uncomfortable that they're using curl|bash for something as simple as "put this 10-line script somewhere in your $PATH," especially when the script involves sudo (to move into /usr/local/bin). Sure, it's easy to inspect the script and see that it's not doing anything malicious, but it makes install processes like this, where it'd be incredibly easy to, seem normal.

Yeah, and it's not even getting the code from an official source; it's coming from a random bit.ly link [created by a contributor][1]. I've [submitted a PR][2] to inline the install script in the README. [1]: https://github.com/thisredone/rb/pull/5 [2]: https://github.com/thisredone/rb/pull/8

Thanks, merged

Re: Show HN: Rb – Turns Ruby into a command line utility

#70

Post by somebehemoth »

Lio wrote: post #58
vinceguidry wrote: post #46

The second I start wanting a bash pipeline, probably around the third pipe, I scrap it immediately and move to using a text editor to write a script. Because if I'm wanting a pipeline, I'm also going to want to store it, and transmit it over the network, and manage it, and put it down and come back to it later. All things perfectly manageable inside a PORO. Bundler even has an inline mode, so you can put everything i…

Don't you loose the easy threading that's inherent in a pipeline of processes though? I love ruby but for throw away jobs I'd be more likely to do it on the command line than a ruby script simply because it would be quicker for me to write and run in a shell. Unless I'm wrong at the very least you wouldn't have to deal with the GIL.

This is a good point. Using Rb with subshell and pipeline would be the best of both worlds?
Post reply on HN