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"; }
Do you have any suggestions as to what I'm doing wrong?

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).

      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.
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.