Actually, in this case the space is being added, not by the output field separator ($,), but by the list separator ($"), because the array slice is stringified. To get what you want, you can either (1) set $" to the empty string (not undef, that gives a warning), or (2) not stringify the array slice in the print statement:

16:14 >perl -wE "my @array = qw(abc def ghi jkl mno); print @array[2,4
+], qq{\n};"
ghimno

16:14 >
[download]

See the entries for $" and $, in perlvar.

Hope that helps,

print "@array[2,4]\n";
[download]

#!/usr/bin/perl -w
use strict;

my @array =
    (
    'abc', 'def', 'ghi', 'jkl', 'mno', 'pqr', 'stu', 'vwx', 'yz '
    );

print @array[2,4],"\n";
__END__
prints:
ghimno
[download]

As pointed out, you probably want $" instead of $,, but in reality, you want to join those elements and print them that way:

my @array =
    (
    'abc', 'def', 'ghi', 'jkl', 'mno', 'pqr', 'stu', 'vwx', 'yz '
    );

my $output = join '', @array[2,4];
print "$output\n";
[download]

Why is that better? Because nobody knows what $" is, but everyone knows what join() is. Always write your software to be as readable as possible :)

Because nobody knows what $" is

Anyone who doesn't know what $" is, almost certainly won't understand @array[2,4], so you better make that:

my $output = join '', $array[2], $array[4];
[download]

But then, even if they know about the function join(), they probably won't understand the statement join, so you'd better make that:

my $output = join( '', $array[2], $array[4] );
[download]

Then, of course, for consistency you should make that last line:

print( "$output\n" );
[download]

But WFT!? Variable names inside quoted strings? That can't be right:

print( $output . "\n" );
[download]

But what the hell is that dot doing there!?

print( join( '', $output, "\n" ) );
[download]

But hang on a minute! Nested function calls!? We can sort that abomination out:

my $output2 = join( '', $output, "\n" );
print( $output2 );
[download]

my @array =
    (
    'abc', 'def', 'ghi', 'jkl', 'mno', 'pqr', 'stu', 'vwx', 'yz '
    );

my $output = join( '', $array[2], $array[4] );
my $output2 = join( '', $output, "\n" );
print( $output2 );
[download]

But, but, but, where are the classes and objects and methods and, and and ... Sod this! I'm going back to a proper language like JavaPy++ Cscript 3000 where fings are dun proply!

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

The issue I have isn't so much with the core Perl behavior, so much as the plethora of built-in global variables in Perl, and the general abuse of globals. For example, in one of my @INC directories I ran ack '^\s*\$\w+::.*=' and read plenty of CPAN modules who set global variables for other packages and don't localize those changes. I've had my code break as a result of other people doing that and it's very hard to track down these bugs.

When you combine the potential for mysterious action at a distance along with the relatively inscrutable punctuation variables, it's a double-whammy in my book. Thus, I used to use local $" = ...;, but I've stopped doing that and recommend join (yes, even with array slices) because it's clear and there's less risk of mysterious side effects.

Cheers,
Ovid

Hire me for training or software development.

Ovid's reference to readability is wrong IMHO, the intent of "@array" is indeed clear.

That's unfortunate because it transformed a perfectly sensible suggestion about robustness - try to avoid global variables if you can, they might bite you in the long run - in a battle for idioms.

Some of your suggestions might be read in that light too, but I'd make them more explicit:

• Variable names inside quoted strings? - are you thinking about overloading the stringification operator?
• But what the hell is that dot doing there!? - are you thinking about overloading the dot operator?
• ... I fail to see a reason why nested function calls might be detrimental from a robustness point of view though.

Operator overloading is definitely possible but highly improbable though as it's quite difficult (at least for me) to overload an operator in every possible scope. I'm eager to see comments about it, I'll be able to learn something about operator overloading at last :).

Anyway... I tend to consider operators safe and the transformations unneeded. (I would stress I in the last statement).

Personally, I always feel a strange tingling when using "@expand_me", and I do so only in very basic situations and temporary print statements for debugging. I prefer Ovid's way in code that has a longer lifespan. This is where I set the line between idiomatic and idiotic (couldn't resist the pun, sorry).

perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Io ho capito... ma tu che hai detto?

Thank you oh so very much for reminding me why I left Perl Monks. I was last here 5 years ago under a name I have long since forgotten the password to, and — to be honest — who I am (or was) is of no consequence. If you need to know who I am to take me seriously, then you've already lost the plot.

Do you remember the "fun" that was this SoPW? I was around for that and wondered why Abigail responded the way he did. Over time I came to understand his position; eventually leading me to quietly walk away a few years after the aforementioned exchange.

I will leave you with two things:

1. Mutating global state is bad. We all know this. Why should Perl special variables get a pass on that?
2. And the last is certainly not the least.

I so want to downvote this. Please stop trying to convert Perl into Java.

Downvote away, I don't mind :) But first read Re^3: What am I not understanding about $,. I assure you I'm not trying to turn Perl into Java; I'm only trying to avoid the potential for abuse of inscrutable global behavior.

Cheers,
Ovid

Hire me for training or software development.