Snader_LB has joined #rubygems
<Snader_LB> hi all
<havenwood> Snader_LB: hi
<Snader_LB> topic could use an update; is there anyone that can update it?
<Snader_LB> proposed new topic:
<Snader_LB> on a different note: anyone here with edit permissions for <https://guides.rubygems.org/> / <https://github.com/rubygems/guides>?
<havenwood> Snader_LB: I can't edit the topic.
<havenwood> Snader_LB: Please open a PR with suggested improvments!
<Snader_LB> allow me to just note it here FWIW, it's minor but perhaps someone will pick it up
<Snader_LB> <https://guides.rubygems.org/security/> gives "gem cert --add <(curl -Ls https://raw.github.com/metricfu/metric_fu/master/certs/bf4.pem)" as a command instruction, but that syntax does not work in every shell
<Snader_LB> that might confuse readers
<Snader_LB> more portable (and better readable) would be: "curl ... | gem ..."
<Snader_LB> at least if that's what's meant
_whitelogger has joined #rubygems
<Snader_LB> hm; no, that's not what's meant
<Snader_LB> in that case i wonder how this works
<Snader_LB> aiui, the output of the command in "<(...)" is taken as a file name, and that file name is given as an argument to the command standing before the "<(...)" ("gem cert --add", in this case)
<Snader_LB> no, not the output; the FIFO file name, which contains the output
<Snader_LB> got it
<Snader_LB> still, it won't work in any shell, e.g., dash(1) does not support it, which is /bin/sh on Debian based systems
<Snader_LB> so in that sense, it might still be better to split the command in two commands: one for downloading the file to a temporary file, and one for importing that file using "gem cert --add <file>"
<Snader_LB> (and the real question would be, why gem(1) can't read such file from standard input)
<Snader_LB> ok, thanks
Snader_LB has left #rubygems [#rubygems]
pombreda_ has quit [Quit: Leaving]
pombreda has joined #rubygems
houhoulis has joined #rubygems
pombreda has quit [Ping timeout: 246 seconds]
pombreda has joined #rubygems