Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^2: Permission denied writing to Windows 10

by BrowserUk (Patriarch)
on Sep 15, 2016 at 13:32 UTC ( [id://1171865]=note: print w/replies, xml ) Need Help??


in reply to Re: Permission denied writing to Windows 10
in thread Permission denied writing to Windows 10

ou will find your path, which is most likely not what you think it is.

That doesn't really gell with what we've discovered so far. 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.

That places the problem firmly in the realms of Perl -- most likely there's something weird about the installation -- rather than anything to do with the OS or permissions.


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.
"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^2: Permission denied writing to Windows 10

Replies are listed 'Best First'.
Re^3: Permission denied writing to Windows 10
by Discipulus (Canon) on Sep 16, 2016 at 07:34 UTC
    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.
      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.
      "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice.
Re^3: Permission denied writing to Windows 10
by Pickwick (Beadle) on Nov 02, 2016 at 10:59 UTC
    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.

      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.
      "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1171865]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2024-04-25 16:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found