Quick RegExp question

wruehl has asked for the wisdom of the Perl Monks concerning the following question:

I need to add a a check to stored string variables in order to make sure no spaces appear in the string stored in the variable. Here's the code that I have so far, but it is giving me syntax errors.

if ($vinputfilelocation =~ m//s/)
    {
    print LOG "There is a whitespace in the input file location parame
+ter, please remove it. \n";
    }

if ($vlagfilepathname =~ m//s/)
    {
    print LOG "There is a whitespace in the flag file location paramet
+er, please remove it. \n";
    }
[download]

Do you have any suggestions as to what I'm doing wrong?

-Bill

Comment on Quick RegExp question Download Code

Replies are listed 'Best First'.
Re: Quick RegExp question by Tanktalus (Canon) on Mar 04, 2008 at 20:17 UTC
I think you mean \s, not /s. That and I'm not sure why a space is of concern... it generally shouldn't be unless you're using system with shell characters (and even then you can get around it).	[reply]
Re^2: Quick RegExp question by wruehl (Acolyte) on Mar 04, 2008 at 20:52 UTC
It actually came out of the fact that someone else(my team lead) mistakenly put a space in a path that didn't contain that space, crashing the script. When I told my team lead he instructed me to create a check for spaces in the variable string path. Thanks for the help. -Bill	[reply]
Re: Quick RegExp question by graff (Chancellor) on Mar 05, 2008 at 02:14 UTC
As Tanktalus said, you want `m/\s/`. But watch out. If a space in the file name can cause a given script to crash, there are other bad things that can also turn up in file names (also as a result of "pilot error", but hey, it happens, as we all know), and these can do more damage than just crashing your script. (I've seen some MS-Windows users put ampersands in file names. Imagine the fun you can have with that in a unix shell environment.) My point is: If the script crashes because there is a space in the file name, there is actually a deeper problem with the script, in terms of what it is doing with the variable(s) that hold the file name(s) -- e.g. passing the variable as part of a quoted string to a shell command (in back-ticks or in a "system()" call) -- and it would be very prudent to fix that (using `quotemeta`, multi-arg system call, totally different logic, etc). Now. Before the next "unexpected" mistake turns up in a file name.	[reply] [d/l] [select]