• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 186
  • Last Modified:

Cannot run scripts using #!/script in Fedora RC3

Just loaded Fedora RC3 and I am still a little lost, but one thing catching me right now is I cannot run scripts that have the embeded first line:
#!/bin/bash
#!/usr/bin/perl

They're just not working.
They files are +x+r and even the simple test file I've tried:
#!/usr/bin/perl
print "Hi\n";

Fails.

perl script_name works
/usr/bin/perl script_name works

Any ideas?
0
Vision
Asked:
Vision
  • 5
  • 3
  • 3
  • +2
1 Solution
 
VisionAuthor Commented:
I should also mention that using ./script_name is also not working.
0
 
koppchaCommented:
Just clarify this.There should not be any space between #! and /usr/bin/perl
0
 
VisionAuthor Commented:
Correct, there is no space
0
Transaction-level recovery for Oracle database

Veeam Explore for Oracle delivers low RTOs and RPOs with agentless transaction log backup and transaction-level recovery of Oracle databases. You can restore the database to a precise point in time, even to a specific transaction.

 
VisionAuthor Commented:
Found my answer.  I was running the scripts from under the public_html directory and it wouldn't let me do that.
0
 
koppchaCommented:
Great ...
Keep up the Good Work :)
0
 
TintinCommented:
There is absolutely no reason I can think of that would prevent you running a script under a particular directory like public_html.  What reason did you come up with?
0
 
koppchaCommented:
Thanks for asking i completely neglected to analyse what could be the reason :(
0
 
oiqbalCommented:
i agree with Tintin,
unsuccessfull in executing a file when their is no syntax error, then may be their is some file permissions problem.

Try changing the file attribute to executable.

chmod 755 <your_file_name>

755 corresponds to user(7),group(5) and others(5).

you can assign read, write and execute access to any of above.

full access = r w x = 7       ,  read only     r w x  =  4     and so on..
                   4 2 1 = 7                            4 0  0 = 4

any question or comment, just post it !
0
 
VisionAuthor Commented:
My best guess, as to a reason, is that removing the inline interpreter ability to function under the public_html directory keeps people from being able to run scrips from a web page.
There is probably a security file some where that blocks that kind of access.

Yes, the permissions are correct, as are the owner & group.
Its weird, the same file that runs under '~', failes under '~/public_html', and any directory under public_html.
(And when I say "runs" & "fails" I mean using ./script_name to run it with #!/usr/bin/perl in the first line of the script)

New security is my best guess at the moment, but I don't know where that perticular piece of security lies.
0
 
TintinCommented:
The only other thing I can think of is ACL's on the directory, although I can't really think of any combinations that would prevent running a script that runs OK in any other directory.
0
 
VisionAuthor Commented:
Blank mind, what are the "ACL's"?
0
 
TintinCommented:
ACL - Access Control List

They give you a more fine grained control as to perms on files/dirs.

For example, you can set an ACL to allow user fred to have write access on a file you own, even if he doesn't have standard Unix write permission.

man -k acl
0
 
NetminderCommented:
User resolved; 400 points refunded and question closed.

Netminder
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 5
  • 3
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now