on such OS the path is always important:
# 64bit cmd.exe launched as Administrator (via right click runas)
C:\Windows\system32>echo wrote > "c:\Program Files\_ONE.txt"
C:\Windows\system32>type "c:\Program Files\_ONE.txt"
wrote
# Perl 32 bit
C:\Windows\system32>C:\path\strP5.22-32\perl\bin\perl.exe -e "system q
+q(echo WroteByPerl > $ARGV[0] ) or die $^E"
"c:\Pro
+gram Files\_TWO.txt"
File esauriti at -e line 1.
# the above error is in italian, as the OS, and means 'There are no mo
+re files.'
# Perl 64 bit
C:\Windows\system32>C:\path\straw64\perl\bin\perl.exe -e "system qq(ec
+ho WroteByPerl64bit > $ARGV[0] ) or die $^E"
"c:\Progra
+m Files\_TWO.txt"
Accesso negato at -e line 1.
# Access Denied
L*
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
| [reply] [d/l] |
on such OS the path is always important:
The path is important on any OS; if you try to write to a path where you do not have permission to write, you will fail. That's as true under Linux as it is under zOS as it is under hpux.
The OP already demonstrated that he has permissions in the directory where he is trying to write; and indeed can write using command line redirection, and it is when trying to create that same file in that same place that Perl is failing; thus the problem is not the OS, or the path, or the permissions, but something screwed with his Perl installation.
So please stop trying to sell your red-herrings here.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
If he can create the file from the command line using shell redirection; there should be no reason that perl running at that exact same command prompt cannot also create/write to the file.
What you were doing was guessing, Process Monitor on the other hand would have told exactly what is happening by the interesting process where, with which args and results. In cases like those guessing is a waste of time if proper tools to tell one are already available.
| [reply] |
What you were doing was guessing, ... In cases like those guessing is a waste of time if proper tools to tell one are already available.
No I wasn't. I was offering my knowledge and experience that says: processes run from within a shell, inherit the same rights and permission as the shell has.
Thus, as the process being run was a 6 line perl script that could not have changed it's permissions, if the OP has permissions to access the file from the command line, he will definitely have those same permissions when running that simple perl script from that same command line. Guaranteed!
Thus, a concise, simple-to-do, guaranteed-conclusive, guaranteed-to-work-everywhere, mechanism of testing whether permissions are the issue, without the need to find, download, install and learn to use your "proper tool" that would not provide any more, nor better, nor more useful information.
So please, take your belated, juvenile, defensive angst elsewhere and stop wasting our time.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |