From @masak

<masak> I should probably use &shell instead of &run in my program, but...
<masak> ...when I use &run, there's no indication at all that things
go wrong. no error. nothing.
<masak> like 'run("echo hi")'
<masak> "On failure to execute, the routines C<fail()>." -- so, since
I use &run in sink context, it should blow up, right?
* masak submits rakudobug

$ nom -e 'say run("this command cannot possibly succeed").WHAT'
Int+{<anon>}()
$ nom -e 'say +run("this command cannot possibly succeed")'
255
$ nom -e 'say ?run("this command cannot possibly succeed")'
False

Yeah, yeah, it's an Int with Bool tendencies. Cute. But this goes
against the above sentence from S29.

From @jnthn

On Mon Mar 04 08​:33​:55 2013, masak wrote​:

<masak> I should probably use &shell instead of &run in my program, but...
<masak> ...when I use &run, there's no indication at all that things
go wrong. no error. nothing.
<masak> like 'run("echo hi")'
<masak> "On failure to execute, the routines C<fail()>." -- so, since
I use &run in sink context, it should blow up, right?
* masak submits rakudobug

$ nom -e 'say run("this command cannot possibly succeed").WHAT'
Int+{<anon>}()
$ nom -e 'say +run("this command cannot possibly succeed")'
255
$ nom -e 'say ?run("this command cannot possibly succeed")'
False

Yeah, yeah, it's an Int with Bool tendencies. Cute. But this goes
against the above sentence from S29.

Today, run and shell always return a Proc, whose exitcode property indicates success or failure. In sink context, an unsuccessful Proc will now throw an exception. Design docs updated to indicate this, and tests cover it in S29-os/system.t.

/jnthn

The RT System itself - Status changed from 'new' to 'open'

@jnthn - Status changed from 'open' to 'resolved'