I see. Yes, guess I may have attempted using & in some temporary script, which then has been launched with "run >NIL: script" in the background, detaching it from any console capable of job control. Using & is more equivalent to "run >console:" I suppose.
No, & is not equivalent to "Run".
I wrote "more equivalent", not that it was equivalent.
"Run" starts a background shell, "&" does not. That means, the input of a program launched with "&" stays connected to the console, just a different console owner. Of course, the default Console-Handler of AmigaOs (aka Tripos) is too stupid to know, but ViNCed does. If you start a program with & and it requests input, the console will tell you and you can switch between the jobs with the "fg" and "bg" commands, and then enter information. "&" is much closer to the Linux/Unix "&" than "Run" ever was. If you start a program with "Run" and it expects input, it will receive nothing.
Well, what you describe is rather messy, with the console doing the job of the shell - again.
$> type ram:test
ping somewhere &
echo haha
$> protect ram:test +s
$> run >NIL: ram:test
.. and presto, requester pops up, asking me to insert CONSOLE:
In other words - "&" only really works "reliably" in ViNCed, where job control is a thing, and the fg and bg scripts are (somewhat) functional.
On plain OS 3.1.4 there is no ViNCEd, using the & becomes rather pointless, not to mention "dangerous".