Re: Strawberry Perl on Windows 10 file test operators do not work as expected

[fireblood]

Something else that I just discovered from reading another post seems relevant. One part of the total picture that I did not initially include in my post here is that many of the files whose existence my script is attempting to determine are on drives other than the default C: drive. In fact, to let the whole cat out of the bag, what my program is attempting to do is create a perl array that holds the identifiers of all currently mounted drives on the current system. It is based on an algorithm that I saw elsewhere where a loop like the following is executed:

package StdHdr;

	require strict;

	our $OS = $^O;

	our @currently_mounted_drives;

	if ($OS eq "MSWin32")

		{
			do {$currently_mounted_drives@currently_mounted_drives = $_ . ":" if -e $_ . ":\\"} for ("A" .. "Z")
		}

	elsif ($OS eq "linux")

		{
			do {$currently_mounted_drives @currently_mounted_drives = "/mnt/" . $_ if -e "/mnt/" . $_} for ("a" .. "z")
		}

	1;

optionally followed by

	print "\nCurrently-mounted drives are the following:\n\n";

	print "$_\n" for @StdHdr::currently_mounted_drives;

	print "\n";

This had been working perfectly in the Linux environment but had been failing in the Windows environment. But the tipoff to what a key part of the problem was, if not the entirety of the problem, was something that I found in a different posting entitled File Existence using "-e" not always working. There was a comment by a participant named tye who zeroed in not only on what a likely cause of the problem might be but also its solution --

Looks like "auto mount" behavior. It is common that checking for a file's existence won't trigger the automatic mounting of the remote file system but that trying to read a file will trigger that.

And therein lies what I think is the answer to my question. The reason why I was getting so many return values indicating nonexistence when I issued the -e command on targets that I knew existed was not because the targets did not exist, but only because they had not been mounted at the time of my inquiry, such that the -e was unable to see them and thereby impatiently provided false return values. I've made some adjustments for that in my program and now it works perfectly in both the Windows and the Linux environment.

Thanks again to all who provided feedback, it was very instructive for me.

P.S.:

C:\Windows\system32>list_drives

Currently-mounted drives are the following:

C:
E:
F:
G:
H:
I:

rbaumann@DESKTOP-VRU1MNM:/mnt/c/Users$ list_drives

Currently-mounted drives are the following:

/mnt/c
/mnt/e
/mnt/f
/mnt/g
/mnt/h
/mnt/i

rbaumann@DESKTOP-VRU1MNM:/mnt/c/Users$

[Discipulus]

Hello fireblood,

I suggest to use specific tools on win32 systems:

discupulus@:D>perl -MWin32API::File -E "say for Win32API::File::getLog
+icalDrives"

C:\
D:\
F:\
L:\
M:\

Or I'd go for some system calls brutally parsing it's output (maybe after this, also -e results):

# admin privileges not required: all drives included network ones:
discipulus@:D> fsutil fsinfo drives

Unità: C:\ D:\ F:\ L:\ M:\

# admin privileges not required: only network ones:
discipulus@:D> net use

Le nuove connessioni non saranno memorizzate.


Stato       Locale     Remota                    Rete

----------------------------------------------------------------------
+---------
             L:        \\bip\root\work\discipulus   Microsoft Windows 
+Network
             M:        \\bip\ROOT\DATA    Microsoft Windows Network
Esecuzione comando riuscita.

# admin required: only logical disks
C:\WINDOWS\system32> wmic logicaldisk get name

Name
C:
D:
F:

L*

[stevieb]

With the way Perl has been going, I don't know if I'd trust things like this:

    if ($OS eq "MSWin32")
    elsif ($OS eq "linux")

I'm still waiting to see if Strawberry comes out with a perl 5.32 or perl 7.xx. Bizarre and frustrating times.

[syphilis]

if ($OS eq "MSWin32")

That has always worked fine for the last 25 years that I've been using perl.
However, I don't assume that it will work as expected forever.
But then I also don't want to guess at what might be needed if the osname is changed.

I'm still waiting to see if Strawberry comes out with a perl 5.32 or perl 7.xx

Recent posts by kmx indicate that he has started work on the next release - see this github thread for example.
I expect it will be perl-5.32.0, though this has not been explicitly stated any place that I know of.

Cheers,
Rob