Yes, I dare to say so ;-) But if that doesn't work, you might also need to check:
- sufficient execution (and reading) permissions: use chmod 755 my_program.pl or at least chmod u+rx my_program.pl to tell the OS that this file is a program
- a $PATH environment variable that contains . (current directory) or the directory your script is stored, e.g. $HOME/bin or ~/bin . Some consider adding "." to the PATH environment variable a security risk. Personally, I wouldn't care too much for an individual account on a private/non-production system (the system owned by you alone). Use echo $PATH to see your current settings. Add a line like export PATH=
".:$PATH""$PATH:." at the end of your ~/.environment or ~.bashrc file (assuming you're using bash). Alternatively you can run your program like ./my_program.pl (if it is in the same directory). OR you save your program in a directory, that is already in your environments PATH variable - like ~/bin (~ is a shortcut for $HOME or /home/koolgirl/ or where your account might be located).
- /usr/bin/perl does really exist
- a file system mounted without 'noexec' attribute (usually the case)
- ... there are more, but the most likely stuff is listed above
I guess, most of these conditions are already met for your system, so all you need to do after editing your
new Perl program is to do a chmod 755 my_program.pl once and run it as ./my_program.pl.
See the PATH-comment if you insist on my_program.pl.
The original problem was that the missing slash prevented the system to find the perl binary which is usually located in /usr/bin/perl but not in usr/bin/perl . It might have worked when you cd to / first, but this is nonsense. Fix the first line and it can be started (potentially) anywhere.
Update: Argl, oko1 is right with the 644 - thanks - how could that happen? (s/644/755/)
In agreement with Oko1's comment the dot is put at the end of the PATH for slightly improved security. A mistyped command or a legal program name that is not within $PATH - or not installed at all - can be executed when injected into the (visited) local directory. The truely paranoid careful and responsible person will use the slightly inconvenient ./my_program.pl form (or install the program in a proper location) and never let a . enter the $PATH variable - an absolute no-no for root and other high previledged users. As said before, no good idea to do that (the dot thing) on a system accessible by other users.
| [reply]
[d/l]
[select] |
sufficient execution (and reading) permissions: use chmod 644 my_program.pl or at least chmod u+rx my_program.pl
I'm afraid the former won't work - you need at least 700 (most commonly 755, equivalent to 'chmod +x my_program.pl') for the file to execute.
Add a line like export PATH=".:$PATH"
And that, I'm afraid, is REALLY dangerous advice. It means that if someone creates a file called, say, "ls-l" (or "mroe", or "tarxvf", etc.) in /tmp (containing any variety of nasty surprises) and koolgirl happens to mistype "ls -l" while in that directory, she will have all of those nasty surprises to deal with. If you're going to add local dir execution, it should always be at the end of the path - never the beginning (i.e. 'export PATH=$PATH:.')
--
"Language shapes the way we think, and determines what we can think about."
-- B. L. Whorf
| [reply] |
I personally believe that you may be even more astonished to learn that under Windows (which works much with "extensions" that OTOH are in turn "mostly" an unexisting concept under *NIX) if you program is somewhere under %PATH% and .pl is included in %PATHEXT%, then you may just call you your program like my_prog. You will only have problems with one kind of shell redirection. But I don't think you care much...
| [reply]
[d/l]
[select] |
