Finding out whether a string contains a certain character can be done with index or regular expressions. In your case, maybe your check would look like:

if (index($args, '*') != -1) {
    die "No * are allowed.\n"
}
[download]

$args =~ s/\*//g;
[download]

Update: Or do you mean the shell is expanding the '*' metacharacter before it gets fed to your code? In this case, your code never sees the asterisk, and the hassle in protecting the user from themself is almost assuredly not worth your time.

If you can't get your users to put the string in quotes (sounds like that would indeed be a problem), then instead of expecting the string on the command line of your script, have the script read the string. Instead of:

 % your_script the string from the user that should not contain * char
+acters
[download]

Have them use your script like:

 % your_script
Enter string> the string from the user that shouldn't contain * charac
+ters
[download]

(Wait until a user enters a contraction instead of a "*" using your old invocation strategy.)

script.pl \*
script.pl '*'
[download]

Otherwise, the shell expands the wildcard when processing the command.

The Linux shells pre-globber your wildcards and convert them to matching filenames; Windows does not.

Since your users are Linux users, they should be familiar with the shell processing rules, and the idea that you could reject any input with more than one @ARGV might be reasonable.

Otherwise, yes, in the Linux environments, you could try to deduce where the wildcard characters were located based on the input your receive, but that's some risky business, as there is a one-to-many relationship there.

For example, what if what comes back is the only file that matches: test1.dat

The following is not a complete list of how you might have gotten that:

• test1.dat
• test*.dat
• test%.dat
• test*.*

I hope you see my point -- given that one result could have come from a multitude of inputs, it's like a one-way trap door encryption algorithm; you can't navigate the canoe back up the river.

I'd be inclined to educate the users to use quotes; with a far second of trying to compensate for this particular human problem.

Don't trust user input. Ever.

That means account for everything that could go wrong in your code.

It's your fault if your program blows something up.

( Said with love. )

(But don't trust user input. Ever. )

How are they executing the script?
How should they be executing the scrpt?
How are you assigning the arg(s) to the single var?

Please post your code, at least up to the point where you're assigning the arg(s) to the var.

After more testing it seems the damage is done before perl evals the args, as the args include the files in that directory. I created a string in the perl script that has the files in the directory (Cwd) and once I detect that string in the args, rather that stripping that string I decided to turn the message into "I told you not to use asterisks". I'll see how that goes. Once spanked, I will just remove the dir listing from the string. BTW They fork the perl script from the bash shell, testing for * like kennethk mentioned resulted in no asterisks ...

You could require them to pass the args as a single string i.e., is quoted, then check @ARGV. If it has more than 1 element, you know they did not execute the script correctly and you (the script) should then die.

That will catch most of the * shell expansion issues, but not all.

$ ls -a
.  ..
$ touch a_file
$ ls -a
.  ..  a_file
$ echo a_*
a_file
$ echo b_*
b_*
[download]

Is my only choice to stick that exact same directory listing into a var and look for that pattern and remove it ?

I don't know where this 256 character limit comes from.
Certainly not from Perl. In Unix, in the olden days, a fairly normal restriction would be 7 full command lines, which would be 7x80 characters or 560. More normal now would be at least 1024 or 2048 characters or even 4096 or even more than that. I don't know why you can't process a huge command line.

It is certainly possible that the shell can expand *.txt into perhaps 2,000 or many, many more file names.

Show some code and example command line inputs. With proper technique, it should be possible to say process an expanded command line with 5,000 arguments with no problem whatsoever.