shebang and ubuntu
Phred Phungus
and perl. That may sound very decadent, but that held me food-wise
until the Super Bowl.
I have a common problem that files tell my that I'm not allowed there.
If I recall my reading, I was referred to chmod(). I've looked at that
several times, and it doesn't seem to take, at least as a man page.
Does perl have a way to manipulate these file permissions?
dan@dan-desktop:~/source42$ perl t1.pl
t1.pl out b1.c~ t1.pl~ .. . b1.c
dan@dan-desktop:~/source42$ ./t1.pl
bash: ./t1.pl: Permission denied
dan@dan-desktop:~/source42$ cat t1.pl
#!/usr/bin/perl
opendir(THISDIR, ".") or die "tja $!";
@allfiles = readdir THISDIR;
closedir THISDIR;
print "@allfiles\n";
# perl t1.pl
dan@dan-desktop:~/source42$
--
fred
Josef Moellers
Have you tried
chmod u+x t1.pl
It has nothing to do with perl.
Josef
--
These are my personal views and not those of Fujitsu Technology Solutions!
Josef M�llers (Pinguinpfleger bei FTS)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://de.ts.fujitsu.com/imprint.html
J�rgen Exner
>I have a common problem that files tell my that I'm not allowed there.
>If I recall my reading, I was referred to chmod(). I've looked at that
>several times, and it doesn't seem to take, at least as a man page.
>
>Does perl have a way to manipulate these file permissions?
>
>dan@dan-desktop:~/source42$ perl t1.pl
What is "~/source42$"? Is that part of your prompt? That is confusing to
say the least!
>t1.pl out b1.c~ t1.pl~ .. . b1.c
>dan@dan-desktop:~/source42$ ./t1.pl
>bash: ./t1.pl: Permission denied
That error message is a bash error message, it has nothing to do with
Perl.
There can be more obscure reasons but most likely you didn't set the
file permissions for t1.pl to executable.
>dan@dan-desktop:~/source42$ cat t1.pl
>#!/usr/bin/perl
One of those more obscure reasons could be that /usr/bin/perl itself is
not executable for you and this is being masked by a different perl
being executed in your first command (did you try 'which perl'?).
jue
ccc31807
> I have a common problem that files tell my that I'm not allowed there.
> If I recall my reading, I was referred to chmod(). I've looked at that
> several times, and it doesn't seem to take, at least as a man page.
I find chmod very easy and intuitive, but I never use the + or -
syntax, I always use the octal syntax, e.g., 'chomd 755 some.file'
Read is 4, write is 2, and execute is 1, so that 755 meas that owner
has read, write, and execute permissions, and that group and other has
read and execute permissions. 644 means that owner has read and write
permissions and group and other only has read. 700 locks out everyone
except the owner.
CC.
Shmuel Metz
at 01:55 AM, Phred Phungus <Ph...@example.invalid> said:
>Does perl have a way to manipulate these file permissions?
Sure; chmod. But wouldn't it be easier to do it in the shell? From
perlfunc:
Changes the permissions of a list of files. The first element of the list
must be the numerical mode, which should probably be an octal number, and
which definitely should not a string of octal digits: 0644 is okay, '0644'
is not. Returns the number of files successfully changed. See also /oct,
if all you have is a string.
$cnt = chmod 0755, 'foo', 'bar';
chmod 0755, @executables;
$mode = '0644'; chmod $mode, 'foo'; # !!! sets mode to
# --w----r-T
$mode = '0644'; chmod oct($mode), 'foo'; # this is better
$mode = 0644; chmod $mode, 'foo'; # this is best
You can also import the symbolic S_I* constants from the Fcntl module:
use Fcntl ':mode';
chmod S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH, @executables;
# This is identical to the chmod 0755 of the above example.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
Phred Phungus
Thanks all for replies. I hope this sticks now. I've made a linuxlog
for this go around and I'm gonna put your comments and this there:
dan@dan-desktop:~/source42$ chmod u + x t1.pl
chmod: invalid mode: `u'
Try `chmod --help' for more information.
dan@dan-desktop:~/source42$ chmod u+x t1.pl
dan@dan-desktop:~/source42$ ls -l
total 32
-rw-r--r-- 1 dan dan 2556 2010-02-07 18:46 b1.c
-rw-r--r-- 1 dan dan 2555 2010-02-07 18:46 b1.c~
-rwxr-xr-x 1 dan dan 13344 2010-02-07 18:47 out
-rwxr--r-- 1 dan dan 138 2010-02-08 01:34 t1.pl
-rw-r--r-- 1 dan dan 31 2010-02-08 01:30 t1.pl~
One sees here the permissions as gcc creates an executable (out).
dan@dan-desktop:~/source42$ ./t1.pl
dan@dan-desktop:~/source42$ chmod 755 t1.pl
dan@dan-desktop:~/source42$ ls -l t1.pl
-rwxr-xr-x 1 dan dan 138 2010-02-08 01:34 t1.pl
dan@dan-desktop:~/source42$ ./t1.pl
dan@dan-desktop:~/source42$ chmod 644 t1.pl
dan@dan-desktop:~/source42$ ls -l t1.pl
-rw-r--r-- 1 dan dan 138 2010-02-08 01:34 t1.pl
dan@dan-desktop:~/source42$ chmod 700 t1.pl
dan@dan-desktop:~/source42$ ls -l t1.pl
-rwx------ 1 dan dan 138 2010-02-08 01:34 t1.pl
dan@dan-desktop:~/source42$ ./t1.pl
chmod seems to have been another instance where my C notion that
whitespace is better has led me astray. Since it's just me on this
machine, I think I'll go with chmod 700 in the future.
Cheers,
--
fred
Phred Phungus
> Phred Phungus <Ph...@example.invalid> wrote:
>> I have a common problem that files tell my that I'm not allowed there.
>> If I recall my reading, I was referred to chmod(). I've looked at that
>> several times, and it doesn't seem to take, at least as a man page.
>>
>> Does perl have a way to manipulate these file permissions?
>>
>> dan@dan-desktop:~/source42$ perl t1.pl
>
> What is "~/source42$"? Is that part of your prompt? That is confusing to
> say the least!
I've got all these refugee directories named source leftover from when I
would use gnu software on windows. Now on linux, not only do I have a
shebang line that does something, but I also have the option of creating
a terminal anywhere I want with a right-click and selection. So I've
got a lot more flexibility than trying bring up a dos terminal quickly.
Since this is x-posted to alt.os.linux.ubuntu, I would be curious where
others like to put their perl scripts.
>
>> t1.pl out b1.c~ t1.pl~ .. . b1.c
>> dan@dan-desktop:~/source42$ ./t1.pl
>> bash: ./t1.pl: Permission denied
>
> That error message is a bash error message, it has nothing to do with
> Perl.
> There can be more obscure reasons but most likely you didn't set the
> file permissions for t1.pl to executable.
>
>> dan@dan-desktop:~/source42$ cat t1.pl
>> #!/usr/bin/perl
>
> One of those more obscure reasons could be that /usr/bin/perl itself is
> not executable for you and this is being masked by a different perl
> being executed in your first command (did you try 'which perl'?).
dan@dan-desktop:~/source42$ which perl
/usr/bin/perl
I've now tripped on another instance of being denied permission:
dan@dan-desktop:/usr/bin$ ls -l >text1.txt
bash: text1.txt: Permission denied
dan@dan-desktop:/usr/bin$ ls -l text1.txt
ls: cannot access text1.txt: No such file or directory
dan@dan-desktop:/usr/bin$
How can a non-existent file deny me permission?
--
fred
sreservoir
> chmod seems to have been another instance where my C notion that
> whitespace is better has led me astray. Since it's just me on this
> machine, I think I'll go with chmod 700 in the future.
well, you're giving chmod two extra arguments. do you expect it to work?
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
tony_c...@yahoo.com
> I've now tripped on another instance of being denied permission:
>
> dan@dan-desktop:/usr/bin$ ls -l >text1.txt
> bash: text1.txt: Permission denied
> dan@dan-desktop:/usr/bin$ ls -l text1.txt
> ls: cannot access text1.txt: No such file or directory
> dan@dan-desktop:/usr/bin$
>
>
> How can a non-existent file deny me permission?
* what is the current directory?
* which user are you?
* which user owns the current directory?
hth
t
sreservoir
he seems to be a non-root user in /usr/bin (usually root:root/wheel).
naturally he wouldn't be able to create a file.
sreservoir
it isn't. the directory is denying creat permission.
sreservoir
are you, by any chance, a former user of one of those OSes that log
one on as root by default?
Jonathan N. Little
> I've now tripped on another instance of being denied permission:
>
> dan@dan-desktop:/usr/bin$ ls -l >text1.txt
> bash: text1.txt: Permission denied
If you are not root you cannot write to the /usr/bin folder
Try
sudo sh -c "ls -l > text1.txt"
Or redirect do a folder that you *do* have write permission
ls -l > ~/text1.txt
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
sreservoir
> Phred Phungus wrote:
>
>> I've now tripped on another instance of being denied permission:
>>
>> dan@dan-desktop:/usr/bin$ ls -l >text1.txt
>> bash: text1.txt: Permission denied
>
> If you are not root you cannot write to the /usr/bin folder
>
> Try
> sudo sh -c "ls -l > text1.txt"
ls -l | sudo tee text1.txt >&-
> Or redirect do a folder that you *do* have write permission
> ls -l > ~/text1.txt
this is probably the best idea, since /usr/bin isn't a good place to
keep directory listings.
J�rgen Exner
>J�rgen Exner wrote:
>> Phred Phungus <Ph...@example.invalid> wrote:
>>> dan@dan-desktop:~/source42$ perl t1.pl
>>
>> What is "~/source42$"? Is that part of your prompt? That is confusing to
>> say the least!
>
>I've got all these refugee directories named source leftover from when I
>would use gnu software on windows. Now on linux, not only do I have a
>shebang line that does something, but I also have the option of creating
>a terminal anywhere I want with a right-click and selection. So I've
>got a lot more flexibility than trying bring up a dos terminal quickly.
???
Is the above meant to be an answer to my question? If yes then I have no
idea what you are talking about.
>>> dan@dan-desktop:~/source42$ ./t1.pl
>>> bash: ./t1.pl: Permission denied
>>
>> That error message is a bash error message, it has nothing to do with
>> Perl.
>> There can be more obscure reasons but most likely you didn't set the
>> file permissions for t1.pl to executable.
>>
>>> dan@dan-desktop:~/source42$ cat t1.pl
>>> #!/usr/bin/perl
>>
>> One of those more obscure reasons could be that /usr/bin/perl itself is
>> not executable for you and this is being masked by a different perl
>> being executed in your first command (did you try 'which perl'?).
>
>dan@dan-desktop:~/source42$ which perl
>/usr/bin/perl
Ok, then it is not this one of the more obscure reasons. My bets are
still on the most trivial: you forgot to make t1.pl executable.
>I've now tripped on another instance of being denied permission:
>
>dan@dan-desktop:/usr/bin$ ls -l >text1.txt
>bash: text1.txt: Permission denied
Ok, I am beginning to suspect that this funny "~/source42$" or now
"/usr/bin$" is supposed to indicate the current working directory.
>How can a non-existent file deny me permission?
If that is the case then does your account have permissions to create a
file in /usr/bin? Hopefully not because otherwise that would be A Very
Bad Idea. You absolutely, totally, completely don't want just any user
to mess around in /usr/bin.
Again, this has nothing at all whatsoever to do with Perl.
jue
J�rgen Exner
>Phred Phungus wrote:
>
>> I've now tripped on another instance of being denied permission:
>>
>> dan@dan-desktop:/usr/bin$ ls -l >text1.txt
>> bash: text1.txt: Permission denied
>
>If you are not root you cannot write to the /usr/bin folder
>
>Try
>sudo sh -c "ls -l > text1.txt"
Of course this begs the question why on earth would somewone want to
create a txt file in /usr/bin?
>Or redirect do a folder that you *do* have write permission
>ls -l > ~/text1.txt
A much saner idea.
jue
Phred Phungus
> "Jonathan N. Little" <lws...@gmail.com> wrote:
>> Phred Phungus wrote:
>>
>>> I've now tripped on another instance of being denied permission:
>>>
>>> dan@dan-desktop:/usr/bin$ ls -l >text1.txt
>>> bash: text1.txt: Permission denied
>> If you are not root you cannot write to the /usr/bin folder
>>
>> Try
>> sudo sh -c "ls -l > text1.txt"
>
> Of course this begs the question why on earth would somewone want to
> create a txt file in /usr/bin?
If you want to see what's in there and you don't have the below advice.
>
>> Or redirect do a folder that you *do* have write permission
>> ls -l > ~/text1.txt
>
> A much saner idea.
dan@dan-desktop:/usr/bin$ ls -l > ~/zax1.txt
dan@dan-desktop:/usr/bin$ locate zax1.txt
dan@dan-desktop:/usr/bin$ man sh
dan@dan-desktop:/usr/bin$ sudo sh -c "ls -l > qext1.txt"
[sudo] password for dan:
dan@dan-desktop:/usr/bin$ locate qext1.txt
dan@dan-desktop:/usr/bin$ ls qext1.txt
I'm so glad I finally figured out this bit here. It will enter my
linuxlog, and so I hope never to ask this question again.
Why did my locate commands not work? The first should have indicated
that the text file was in the home folder, and the second is in the same
directory whence the locate originates.
--
fred
tony_c...@yahoo.com
> Why did my locate commands not work? The first should have indicated
> that the text file was in the home folder, and the second is in the
> same directory whence the locate originates.
This is now off-topic for clpm, but locate looks at a
pre-built index file, which is updated regularly (but
obviously not every 2 seconds or so :-).
comp.os.linux.misc may be your best bet for permissions
issues.
hth
t
Dan C
Jesus, you're fucking stupid even for a n00b. Almost so stupid that one
would have to believe you're just deliberately trolling.
Bugger off, stupid troll boy.
--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
"Bother!" said Pooh, as he found his pit crew eating ice cream.
Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/
Martijn Lievaart
> dan@dan-desktop:/usr/bin$ ls -l > ~/zax1.txt dan@dan-desktop:/usr/bin$
> locate zax1.txt dan@dan-desktop:/usr/bin$ man sh
> dan@dan-desktop:/usr/bin$ sudo sh -c "ls -l > qext1.txt" [sudo] password
> for dan:
> dan@dan-desktop:/usr/bin$ locate qext1.txt dan@dan-desktop:/usr/bin$ ls
> qext1.txt
>
> I'm so glad I finally figured out this bit here. It will enter my
> linuxlog, and so I hope never to ask this question again.
>
> Why did my locate commands not work? The first should have indicated
> that the text file was in the home folder, and the second is in the same
> directory whence the locate originates.
Locate works on a database that is created each night.
I think you would be better of in a unix/linux newsgroup. Your questions
are VERY basic unix questions and have NOTHING to do with perl.
M4
Josef Moellers
> Since this is x-posted to alt.os.linux.ubuntu, I would be curious where
> others like to put their perl scripts.
It depends (aus usual).
If you feel that it is a generic script and should be made available to
anyone using the system, the best place to put it would be
/usr/local/bin (it not being a generally avaliable script). If you just
want to keep it to yourself, put it into the bin-directory inside your
home-directory: $HOME/bin.
> I've now tripped on another instance of being denied permission:
>
> dan@dan-desktop:/usr/bin$ ls -l >text1.txt
> bash: text1.txt: Permission denied
> dan@dan-desktop:/usr/bin$ ls -l text1.txt
> ls: cannot access text1.txt: No such file or directory
> dan@dan-desktop:/usr/bin$
>
>
> How can a non-existent file deny me permission?
It's not the file which denies you permission, it's the directory.
"/usr/bin" is a directory which holds system-wide commands and is
writable only by the super-user "root", or else anyone could put trojans
there.
You can check a directory's permissions with
ls -ld <directoryname>
e.g.
ls -ld /usr/bin
drwxr-xr-x 2 root root 69632 2010-02-08 15:48 /usr/bin
This means:
it's a directory ("d"),
The owner (the first "root") may read, write, and search ("rwx"),
anyone belonging to the group "root" (the second "root", users and
groups can have the same name) may read and search but not write (the
first "r-x") and the resto of the world may read and searcg but not
write (the second "r-x").
The large number is the size in bytes of the directory index (so to
speak) and is of little importance. The next is the date and time of the
last modification of that directory (e.g. a new file was created in that
directory), followed by the name of the directory.
HTH,
prawn
> others like to put their perl scripts.
/usr/local/bin for anything I write.
--
Leviticus 11:10
Keith Thompson
[...]
> dan@dan-desktop:~/source42$ chmod u + x t1.pl
> chmod: invalid mode: `u'
> Try `chmod --help' for more information.
> dan@dan-desktop:~/source42$ chmod u+x t1.pl
> dan@dan-desktop:~/source42$ ls -l
> total 32
> -rw-r--r-- 1 dan dan 2556 2010-02-07 18:46 b1.c
> -rw-r--r-- 1 dan dan 2555 2010-02-07 18:46 b1.c~
> -rwxr-xr-x 1 dan dan 13344 2010-02-07 18:47 out
> -rwxr--r-- 1 dan dan 138 2010-02-08 01:34 t1.pl
> -rw-r--r-- 1 dan dan 31 2010-02-08 01:30 t1.pl~
Personally, I find the repeated occurrences of your rather long
shell prompt districting. They make it more difficult to read the
actual information. I'm sure I'm not the only one who thinks so.
I suggest shortening your prompt to something like "$ ". You can
do this by (carefully!) editing the output after you copy-and-paste
it, but that risks losing information. It's probably safer to
change your prompt, run the commands, copy-and-paste the output,
and then change it back. (I'm not suggesting you should change the
prompt for your own use, only for what you post here.)
For example, the above would be:
$ chmod u + x t1.pl
chmod: invalid mode: `u'
Try `chmod --help' for more information.
$ chmod u+x t1.pl
$ ls -l
total 32
-rw-r--r-- 1 dan dan 2556 2010-02-07 18:46 b1.c
-rw-r--r-- 1 dan dan 2555 2010-02-07 18:46 b1.c~
-rwxr-xr-x 1 dan dan 13344 2010-02-07 18:47 out
-rwxr--r-- 1 dan dan 138 2010-02-08 01:34 t1.pl
-rw-r--r-- 1 dan dan 31 2010-02-08 01:30 t1.pl~
which I find much easier to read.
The only useful part of the prompt is the current directory, but
you could achieve that by using an explicit "cd" command. (It's not
really necessary here, since knowing that you're in ~/source42
doesn't help us.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Phred Phungus
I think Keith's point goes to readability on usenet, which can stand a
couple posts without disrupting anything. I had also wanted to shorten
that prompt, which one does by editting the .bashrc that appears in your
home folder. One replaces occurences of PS1 = ... to export PS1="\$ "
and gets
$ echo "looking better?"
looking better?
$
--
fred