You almost have it. What you are missing is that the list assignment
operator is in scalar context and is returning the count, not the list
being assigned to. Infix operators obscure things sometimes. It is easier
to understand if we rewrite it as if list assignment was a function call
instead
On Tue, Oct 4, 2016 at 2:07 PM, X Dungeness wrote:
> Here's a possibly relevant note in the docs for both "alarm" and
> "sleep":
>
> It is usually a mistake to intermix "alarm" and "sleep" calls,
> because "sleep" may be internally implemented on your system
> with
To summarize
There is a list assignment and the difference between assigning to an
empty list and an non empty list is the container(s) inside the liste
that capture the different values (scalars or lists or hashes)
for example () ans ($a, @b, %c... )
when we assign to an ampty list the values
Here's a possibly relevant note in the docs for both "alarm" and
"sleep":
It is usually a mistake to intermix "alarm" and "sleep" calls,
because "sleep" may be internally implemented on your system
with "alarm".
On Tue, Oct 4, 2016 at 1:34 PM, Chas. Owens
The first alarm is in a different process (same PID different process) due
to the exec. I am not sure what is happening, but in general it is never a
good idea to do anything complex in a signal handler.
On Tue, Oct 4, 2016 at 4:21 PM Shawn H Corey wrote:
> On Tue, 04 Oct
On Tue, 04 Oct 2016 19:32:44 +
"Chas. Owens" wrote:
> It looks like the problem exists at the C level as well. This code
> doesn't work past the first alarm:
Doesn't it say the alarm has to be reset by the code in the
documentation? After all, you don't want a second
It looks like the problem exists at the C level as well. This code doesn't
work past the first alarm:
#include
#include
#include
#include
#include
int n;
char s[10];
char* prog;
int alarm_called = 0;
void handle_alrm(int signo) {
if (signo == SIGALRM) {
execv(prog, (char*[]) { prog, s,
First, never use -w flag to enable warnings; use the warnings pragma
instead.
Second, you should not exec the script directly, you don't know if it is
executable or not, and it could even wind up running under a different
version of perl. Instead, you should exec same the interpreter that is
On Mon, Oct 3, 2016 at 10:45 PM Lawrence Statton wrote:
snip
> the =()= "operator" just does that without creating a temporary variable
snip
Almost, but not quite. You can see the difference when =()= is in list
context:
my @a = (my @temp) = get_clown_hat;
my @b = () =