My assumption was that there is only one match based on the OP's comment that print would work ok and that he wanted to assign to scalar as map would only return one value. If this assumption is incorrect, then one needs to change the approach.

In order to clarify some of the arguments in the thread and based on the assumption of only one match, please have a look at the following list of experiments:

use strict;
use warnings;

my @match = map { /(2)/ ? $1 : () } 0..9;
print scalar @match, "\n"; # is 1, no grep required

@match = map { /(2)/ } 0..9;
print scalar @match, "\n"; # is 1

@match = map { $1 if /(2)/ } 0..9;
print scalar @match, "\n"; # is 10

@match = grep { defined } map { $1 if /(2)/ } 0..9;
print scalar @match, "\n"; # is 10

@match = grep { length } map { $1 if /(2)/ } 0..9;
print scalar @match, "\n"; # is 1
[download]

From this I would conclude that the easiest-to-write version for the OP is indeed

my ($val) = map { /^\*\s\(?([^\)]+)\)?/ } @GET_STRING;
[download]

not considering any performance issues. If there is more than one match, this just returns the first one, which might or might not be ok.

The whole discussion highlights that sometimes the best thing to do might be to use a for loop and be done with it. Probably the fastest solution here as well depending on the data:

my $val;
for (0..9) {
    if( /(2)/ ) {
        $val = $1;
        last;
    }
}
[download]

From ram31's OP:

I am using the below code and it works when i use print. I want to assign it to scalar variable because only one element will be the output of map.

One has to do a lot of guessing when reading a post like this. Does "... one element will be the output of map" mean that that's what ram31 wants to be the case, or is it an assertion that it is the case? It's easy to demonstrate, as you have done, that the latter is false: there is an empty string output for every non-match in the map input for the  $1 if /(...)/ sub block code. The suspicion that ram31 did not understand this was bolstered by the statement "... it works when i use print" because print, with the default  $, value, simply masks the presence of all those empty strings.

That's how I arrived at my assumption that the  @GET_STRING array could contain any number of matching and non-matching strings in any order, and, from the OPed code, that ram31 wanted to extract and return a sub-string from the first (i.e., lowest-index) match. (The assumption of any number of matching strings was defensive.)

So I was at some pains to explain to ram31 why many empty strings would potentially be generated by the OPed code, and that there was another approach that entirely avoided this complication. (It remained for runrig to point out the most elegant and, I believe, most efficient approach.)

So what? The fact remains that, as you and I and others have pointed out, a for-loop approach remains the most efficient for what I understand ram31 to want. Be that as it may, ram31 specifically wrote that he or she was aware of that approach and was instead interested in a map approach. So that's what we've all spent most of our time and effort discussing. Caveat praeceptor.

So what's the point of this reply? None, really, except that I enjoyed reading your thoughtful and detailed post and I wanted to respond in kind.

Thanks for your response! As I did not get around to respond to you last night (too late for me), this morning I felt like writing a concise summary of what was going on in the different parts of this thread. There is no additional information in this beyond what was already said elsewhere but it helped me to clarify things in my mind. Whether or not it is helpful to anyone else I do not know.