Perl m// grouping context

m// always returns an array when used with () matches, even if there is only one match. Eg you must say

@a = m/Time (L...)/;

($a) = m/Time (L...)/;

If you assign just to $a in this situation, you'll get the scalar value of the array of matches, in this case 1.

Don't be fooled by testing it with print. print takes a list as its argument - it concatenates all its elements and then prints the result - so it's equivalent to the @a example.

Perl glob

Under Win32, if you supply glob() with a string that doesn't contain any wildcards, and there are no files matching your string, you get back one result (your original string). I suppose this makes sense if you are globbing an argument supplied by the user, which might be a single filename or a wildcard spec.

If there are results, they will have a path prefix if there was one in the argument you gave glob. And they won't if there wasn't.

Additionally, the results won't include any subdirectory names that match the wildcard.

Furthermore, with a UNC path you have to represent the leading \\ as \\\\\\\\ - 8 backslashes even in a single quoted string. But you don't have to have more than 1 backslash at any other place in the path.

And beware, you may need to prefix with use File::DosGlob 'glob'; to make glob work natively. NB that even this does not undo the UNC path issue mentioned above - the string that glob is given internally needs 4 consecutive backslashes, and if you construct that string using quotes, the quoted literal needs 8 backslashes.

The documentation says: As a concession to user expectation, therefore, backslashes (under GLOB_QUOTE) only quote the glob metacharacters '[', ']', '{', '}', '-', '~', and backslash itself. All other backslashes are passed through unchanged and this appears to be the same under File::DosGlob.

Further beware that a pattern with a space in won't work in either mode - without the use, glob behaves like split(m/ /,...), and with the use, it returns an empty array.

When are Perl globals initialised?

Code in the main part of a package file (outside any subs) runs during the compilation phase, ie when the "use" statement that loads the package is read by the compiler.

If you set globals (such as package 'locals') in such code, they will not still be set during execution - I'm guessing because globals are initialised to undefined when execution proper begins?

But then if I use a BEGIN block to set globals, they are still set when execution begins, even though BEGIN blocks are supposed to run during compilation too.

The import sub is also a suitable place to use as a workaround (presumably because it runs after BEGIN).

So I have a workaround for this, but I don't know why it works and the other way doesn't.

Perl line number

$. is 1-based. Before any lines have been read it's undefined.

Reading and writing to the same file

Firstly, don't use +> with open, as this truncates the file on opening.

Secondly, +< works, but it appends to the file. You can seek back to the start for reading, but anything you write will go on the end of the file, no matter where the last read was from.