[32612] in Perl-Users-Digest
Perl-Users Digest, Issue: 3886 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Feb 24 18:09:23 2013
Date: Sun, 24 Feb 2013 15:09:06 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 24 Feb 2013 Volume: 11 Number: 3886
Today's topics:
should we Go now? <oneingray@gmail.com>
Re: should we Go now? <rweikusat@mssgmbh.com>
Re: should we Go now? <oneingray@gmail.com>
Re: should we Go now? <rweikusat@mssgmbh.com>
Re: should we Go now? <ben@morrow.me.uk>
Re: should we Go now? <rweikusat@mssgmbh.com>
Re: Unlink help - Solved - sort of <dave@invalid.invalid>
Re: Unlink help <dave@invalid.invalid>
Re: Unlink help <ben@morrow.me.uk>
Re: Unlink help <dave@invalid.invalid>
Re: Unlink help <maus@mail.com>
Re: Unlink help <ben@morrow.me.uk>
Re: Unlink help <hjp-usenet3@hjp.at>
Re: Unlink help <dave@invalid.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 24 Feb 2013 10:47:56 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: should we Go now?
Message-Id: <87hal29eeb.fsf@violet.siamics.net>
[Cross-posting also to news:comp.lang.perl.misc and
news:comp.lang.c, as Go seem to be positioned as a successor to
both the "system programming languages" (C) and the "Web
programming languages," of which Perl is one I'm familiar with.
Setting Followup-To: news:comp.lang.misc only, though.]
Introduction
Becoming interested in this relatively new "Go" programming
language [1] (now that I've found that its libraries' collection
may even outshine CPAN, depending on the task at hand; I'm yet
to check the quality of the code, though), I've decided to check
its FAQ [2], and some of the related documents. There, I've
found a few design choices described which I'd like to comment
on. Certainly, there may be some misunderstanding on my part,
hopefully to be resolved in the discussion.
TIA.
[1] https://en.wikipedia.org/wiki/Go_(programming_language)
[2] http://golang.org/doc/faq
An unusual control flow feature
For me, one of the most notable features of Go seems to be its
"defer" statement. To quote [3]:
> A defer statement pushes a function call onto a list. The list of
> saved calls is executed after the surrounding function returns.
> Defer is commonly used to simplify functions that perform various
> clean-up actions.
And the code example follows:
> func CopyFile(dstName, srcName string) (written int64, err error) {
> src, err := os.Open(srcName)
> if err != nil {
> return
> }
> defer src.Close()
> dst, err := os.Create(dstName)
> if err != nil {
> return
> }
> defer dst.Close()
Certainly, this feature could simplify such clean-ups in the
code; the only other way for such simplification I know of is to
introduce additional functions all along the way.
Somehow, "defer" looks quite Perl-ish to me! (Such nice control
features are characteristic of the Scheme programming language,
too, but there "defer" would be too "imperative" to implement.)
I wonder if there's a clever way to bring "defer" to, say, Perl?
[3] http://golang.org/doc/articles/defer_panic_recover.html
Exceptions and assertions
The stance of the language designers on exceptions does (for the
most part) match my experience with them: which is little. To
quote the FAQ [2]:
> Why does Go not have exceptions?
> We believe that coupling exceptions to a control structure, as in the
> try-catch-finally idiom, results in convoluted code. It also tends
> to encourage programmers to label too many ordinary errors, such as
> failing to open a file, as exceptional.
And then [3]:
> The convention in the Go libraries is that even when a package uses
> panic internally, its external API still presents explicit error
> return values.
Also per my experience with CPAN packages, exceptions are rarely
used there, with most of the code I've seen returning "undef"
instead (which is known in Go as "nil", AIUI.)
The assertions go next:
> Why does Go not have assertions?
> Go doesn't provide assertions. They are undeniably convenient, but
> our experience has been that programmers use them as a crutch to
> avoid thinking about proper error handling and reporting. Proper
> error handling means that servers continue operation after non-fatal
> errors instead of crashing.
Which is contrary to my experience, which says that for a
prototype (which may or may not become a "real" project later),
it's far better to have an "assert ()"-, or "or die"-ridden,
code, than to waste time thinking about "proper" error
reporting. The latter may even be impossible at a given stage
of development, "thanks" to the relative unfamiliarity of the
coder with the new libraries, protocols, file formats, etc.
Unfortunately, C-style assertions in Go would likely require a
separate syntactic construct. Perhaps a simple panic () may fit
the majority of cases, however.
Expressions and statements
Being familiar with the languages of the Lisp family (mostly
Scheme and Emacs Lisp), I don't believe in the necessity of firm
separation of the "statement" and "expression" contexts. C and
Perl are rather close to Lisp in this respect, given that, for
instance, the assignment operator forms an "expression" in both
(while in other languages it may be a "statement" instead.)
At least one modern C implementation (GCC) goes a bit further
and allows statements almost anywhere in expressions. Also,
both C and Perl provide three conditional operators for use
within expressions: binary &&, ||, and the ternary ? :. (Perl
provides a few more, but it isn't all that relevant here.)
Unfortunately, Go seem to take a step back there. Consider [2]:
> Does Go have the ?: operator?
> There is no ternary form in Go. You may use the following to achieve
> the same result:
> if expr {
> n = trueVal
> } else {
> n = falseVal
> }
In my opinion, this latter form is more error-prone, just as the
"a = a + b" form is more error-prone than "a += b", -- thanks to
the duplication of the identifier.
Also, with several choices being handled, this can easily expand
the code quite a bit. Consider, e. g.:
a = (foo_p ? foo
: bar_p ? bar
: baz_p ? baz
: qux);
which has to be transformed to, say:
switch {
case foo_p:
a = foo;
case bar_p:
a = bar;
case baz_p:
a = baz;
case true:
a = qux;
}
There's one more notable difference in having two particular
operators form statements, and not expressions.
> Why are ++ and -- statements and not expressions? And why postfix,
> not prefix?
> Without pointer arithmetic, the convenience value of pre- and postfix
> increment operators drops. By removing them from the expression
> hierarchy altogether, expression syntax is simplified and the messy
> issues around order of evaluation of ++ and -- (consider f(i++) and
> p[i] = q[++i]) are eliminated as well. The simplification is
> significant.
I have some doubt regarding whether this decision is justified
or not. For instance, even though the pointer arithmetic is
gone (the inconveniece of which is partly remedied by an easier
to use "slicing" feature), wouldn't it still be convenient to
write, say, a[i++] = b[j++]? Go doesn't allow for that.
The matters of style
One more notable decision made for Go is that it allows for a
newline to end a statement (unless it leads to an error), thus
eliminating most of the semicolons one'd find in a similar C
code, and is (AIUI) similar to the AWK approach. The price to
pay for that is that there can't be a newline before the
function definition's opening brace:
func () foo() {
// ...
}
... Frankly, I don't seem to recall for a major programming
language designer /not/ to advocate for a particular coding
style. (And so for the major users.)
The all-time low record in this respect is probably set by the
Python language, which goes as far as to hardwire a particular
coding style into the language syntax itself (which made Python
a no-go for me.) Go seem to take a gentler approach here [2]:
> Since Go code is meant to be formatted automatically by gofmt, some
> style must be chosen. That style may differ from what you've used in
> C or Java, but Go is a new language and gofmt's style is as good as
> any other. More important -- much more important -- the advantages of a
> single, programmatically mandated format for all Go programs greatly
> outweigh any perceived disadvantages of the particular style.
Instantly, I began to think if there could be a person brave
enough to fork gofmt (or write a similar tool anew) to provide
for a set of parameters to adjust comparable to that of
GNU Indent [4]!
A particular point is that there's an old typographic convention
of spacing the parenthesis from the outside (as in "a (b) c"),
which Go seem to forgo at times, and which I'd like to get back.
[4] http://www.gnu.org/software/indent/manual/
--
FSF associate member #7257 np. The Clairvoyant -- Iron Maiden
------------------------------
Date: Sun, 24 Feb 2013 16:37:04 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: should we Go now?
Message-Id: <87ehg5u0r3.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
> [Cross-posting also to news:comp.lang.perl.misc and
> news:comp.lang.c, as Go seem to be positioned as a successor to
> both the "system programming languages" (C) and the "Web
> programming languages," of which Perl is one I'm familiar
> with.
I'm using Perl for 'system programming' and 'Go' won't replace it (it
also won't replace C) for the simple reason that it uses another "I
swallowed the Kool Aid and it was sure tasty!" runtime environment:
Deterministic object finalization based on lexical scopes is not only
a very powerful and easy-to-use way to manage all kinds of resources,
not just memory, it is also a useful programming paradigm beyond
resource management. As an example, in a certain program, I'm using
some classes to facilitate construction of (Linux) kernel IPset
objects. These provide interfaces for adding data to such an object
(either 'CIDR addresses' or port numbers) and construct the actual
kernel object during execution of DESTROY[*]. That's the sensible way
to make this happen automatically because if the object is going away,
new members won't be added to the set anymore.
Tracing garbage collectors, OTOH, are an exercise in academic
masturbation 'hard-coded' around a couple of assumptions about the
execution environment of the original Lisp implementation (AFAIK, an
IBM 704 machine) such as 'no multiprogramming, no networking, single
userspace application in total control of the environment, pointers
are not data' which essentially haven't been true anywhere since (it
was demonstrated that general purpose computers can run Lisp code
faster than 'Lisp machines' 20 years ago) and offer no real advantages
except that they can solve toy problems specifically invented to
demonstrate the usefulness of these memory management algorithms
(something people who presently can't use some important application
written in Java because it is leaking file descriptors very likely
don't care about).
I spent the last 1.5 weeks mostly with writing Java code and having to
write code which explicitly release a 'lock objects' managed outside
of the JVM instead of creating a class instances of which will release
their locks 'at the right time' during object destructions felt pretty
much like 'stone age coding' to me (NB: I didn't research how
finalization works in Java and may assumption that it is coupled to
the garbage collector may be wrong). perl can do better than that.
[*] I'm aware that this is another feature in the process of becomeing
'documented away' because it is considerd to be politically incorrect
to provide it.
------------------------------
Date: Sun, 24 Feb 2013 17:02:06 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: should we Go now?
Message-Id: <874nh1abn5.fsf@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
[...]
>> as Go seem to be positioned as a successor to both the "system
>> programming languages" (C) and the "Web programming languages," of
>> which Perl is one I'm familiar with.
> I'm using Perl for 'system programming' and 'Go' won't replace it (it
> also won't replace C) for the simple reason that it uses another "I
> swallowed the Kool Aid and it was sure tasty!" runtime environment:
[...]
> a couple of assumptions about the execution environment of the
> original Lisp implementation (AFAIK, an IBM 704 machine) such as 'no
> multiprogramming, no networking, single userspace application in
> total control of the environment, pointers are not data' which
> essentially haven't been true anywhere since
Doesn't seem to be all that applicable to Go. Consider that:
* Perl uses GC;
* so does Emacs;
* Go provides multiprogramming facilities "out of box";
* Go seem to have a decent networking library;
* Go has pointers.
Somehow, Go seem to lack destructors, although I don't quite
understand how this goes well along with having a GC. But
perhaps it doesn't.
Other than that, my most major objection to Go's design
currently is its syntax.
[...]
--
FSF associate member #7257
------------------------------
Date: Sun, 24 Feb 2013 19:38:12 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: should we Go now?
Message-Id: <87y5edcxjv.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
>
> [...]
>
> >> as Go seem to be positioned as a successor to both the "system
> >> programming languages" (C) and the "Web programming languages," of
> >> which Perl is one I'm familiar with.
>
> > I'm using Perl for 'system programming' and 'Go' won't replace it (it
> > also won't replace C) for the simple reason that it uses another "I
> > swallowed the Kool Aid and it was sure tasty!" runtime environment:
>
> [...]
>
> > a couple of assumptions about the execution environment of the
> > original Lisp implementation (AFAIK, an IBM 704 machine) such as 'no
> > multiprogramming, no networking, single userspace application in
> > total control of the environment, pointers are not data' which
> > essentially haven't been true anywhere since
>
> Doesn't seem to be all that applicable to Go.
Since you deleted the core part of my statement, the remainder doesn't
make sense anymore and is hence not 'applicable' to anything.
> Consider that:
>
> * Perl uses GC;
perl implements automatic memory management by keeping track of
'object references' where each reference is supposed to represent 'a
user of the object', not based on the inherently wrong assumption
that future use of an object will be impossible if no pointer to it
can be found within the address space of a single process at an
essentially arbitrary time. This implies (as I wrote in the part of my
text you've chosen to ignore) that the lifetime of perl objects
created in a particular block will usually end when the corresponding
block is exited which is very useful manageing resources other than
memory (such as database locks in the case of the example I gave for
that) and can be utilized in other ways to cause certain code to be
executed automatically 'when the time is right for that' (I also gave
an example for that).
The same is not true for the Go runtime environment because it uses
'some kind of mark & sweep' garbage collector.
[...]
> * Go provides multiprogramming facilities "out of box";
The 'usual' meaning of the term 'multiprogramming' (I'm aware of)
refers to running more than one program on a given computer
concurrently, exploiting (nowadays) a combination of 'multiple
execution units' (processor cores or processers), preemtive
task-switching and hardware facilities to separate different processes
from each other. This implies that pointers to a certain object could
exist in the address space of another process (the garbage collector
cannot inspect) or in the kernel (the garbage collector also cannot
inspect), an example of that would be the Linux 'epoll' interface
which is capable of keeping track of a 'caller supplied pointer'
associated with a file descriptor which will be provided in case of an
I/O event on this descriptor.
------------------------------
Date: Sun, 24 Feb 2013 21:42:58 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: should we Go now?
Message-Id: <24eqv9-9mq.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
>
> Doesn't seem to be all that applicable to Go. Consider that:
>
> * Perl uses GC;
Perl uses refcounting. One of Perl's flaws is that it doesn't use proper
GC.
> * so does Emacs;
>
> * Go provides multiprogramming facilities "out of box";
>
> * Go seem to have a decent networking library;
>
> * Go has pointers.
Real pointers, or Perl-style safe references? Real pointers are a major
disadvantage, in my book, for any language which isn't C.
> Somehow, Go seem to lack destructors, although I don't quite
> understand how this goes well along with having a GC. But
> perhaps it doesn't.
True GC and destructors don't play very well together, because objects
get destroyed at arbitrary times. Mechanisms like the 'defer' you
mentioned originally are more appropriate for cleaning up non-memory
resources.
Ben
------------------------------
Date: Sun, 24 Feb 2013 22:26:43 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: should we Go now?
Message-Id: <87hal1cpr0.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>
>> Doesn't seem to be all that applicable to Go. Consider that:
>>
>> * Perl uses GC;
>
> Perl uses refcounting. One of Perl's flaws is that it doesn't use proper
> GC.
What you believe to be 'proper automatic memory management' is based
on a set of flawed assumptions about the execution environment of a
program[*] (and really dated flawed assumptions, as they go back to the
original Lisp implementation in the 1950s) and has other practical
drawbacks. The memory management approach used by perl 5 is the same
approach which is commonly used in OS kernels. By your reasoning, the
people writing such kernel code have no clue about 'proper memory
management' (This is an appeal to authority and logically not a sound
argument. But simply asserting that what works is 'flawed' and what
doesn't is 'proper' also isn't).
[*] In particular, a tracing collector tries to guess if an object can
be used again in future based on whether there's currently reachable
pointer to it in the sole 'process address space' it can examine
(which was no problem on an IBM 704 because it didn't have virtual
memory) instead of tracking 'object users'. This implies that pointers
must be treated as 'especially magic quantum state' existing outside
of the laws of physics in some magic way which inherentely ties them
to this particular address space. And this is wrong. A pointer is just
a piece of data and it can be written to files, communicated to other
processes on the same machine, communicated to other process on
different machines on a network, be stored in the kernel,
aritmetically transformed to a different value and transformed back to
the original one etc and all of these operation have 'really existing'
practical uses.
------------------------------
Date: Sat, 23 Feb 2013 13:32:33 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Unlink help - Solved - sort of
Message-Id: <fV45K0OBJxbE-pn2-odrtHdEBg6O9@paddington.bear.den>
On Sat, 23 Feb 2013 12:31:45 UTC, "Dave Saville"
<dave@invalid.invalid> wrote:
<snip>
> Upon reflection I guess it must be an OS thing - I really just posted
> here in case there was an option to unlink I did not know about.
Well sort of - For the last few weeks I have been using a linux system
and once again got used to believing the permissions displayed by ls.
It would seem that I was right the first time and it is read only
files - despite what ls was telling me. OS/2 sort of supports file
perms although it does not do much with them. ls was saying the file
was rw whilst attrib said read only. The odd thing is if you chmod the
file with any old mix of perms you like ls *and* attrib reflect them.
Ho hum. Quick fix as Ben suggested is to chmod the file 777 before
trying to delete it.
--
Regards
Dave Saville
------------------------------
Date: Sat, 23 Feb 2013 10:53:12 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Unlink help
Message-Id: <fV45K0OBJxbE-pn2-D0QHfJVD9R67@paddington.bear.den>
On Sat, 23 Feb 2013 09:49:38 UTC, "Dave Saville"
<dave@invalid.invalid> wrote:
> I have a perl script that cleans up temporary directories at boot. If
> a file in one of those directories is read only I get a "permission
> denied" message from unlink. Note this is not a *nix or Windows
> system. If OTOH I cd to said directory and issue "rm -f *" they go
> without a murmur.
>
> Can unlink be made to behave like "rm -f" or do I have to use the
> command in backticks?
>
My mistake - it is not files that are read only. I can see no
difference between files it will delete and those it won't It usually
happens when it is trying to delete an unloaded tarball - some of the
files give "permission denied".
--
Regards
Dave Saville
------------------------------
Date: Sat, 23 Feb 2013 11:57:09 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Unlink help
Message-Id: <ldnmv9-a31.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> On Sat, 23 Feb 2013 09:49:38 UTC, "Dave Saville"
> <dave@invalid.invalid> wrote:
>
> > I have a perl script that cleans up temporary directories at boot. If
> > a file in one of those directories is read only I get a "permission
> > denied" message from unlink. Note this is not a *nix or Windows
> > system.
What sort of system is it?
> > If OTOH I cd to said directory and issue "rm -f *" they go
> > without a murmur.
> >
> > Can unlink be made to behave like "rm -f" or do I have to use the
> > command in backticks?
Unlink alone cannot be made to do anything other than call unlink(2) (or
your local equivalent). If your system uses Unix-like permissions, or if
perl emulates them sufficiently, you can change the relevant permissions
with chmod before trying the unlink. You can also use
File::Path::rmtree, which will do this for you.
If you do decide to run rm(1), do it with system rather than backticks.
> My mistake - it is not files that are read only. I can see no
> difference between files it will delete and those it won't It usually
> happens when it is trying to delete an unloaded tarball - some of the
> files give "permission denied".
Under Unix you need write permission to a directory to delete files in
it. If that's not the case on your system you will need to find out what
is making the difference.
Ben
------------------------------
Date: Sat, 23 Feb 2013 12:31:45 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Unlink help
Message-Id: <fV45K0OBJxbE-pn2-morqdnKtisOu@paddington.bear.den>
On Sat, 23 Feb 2013 11:57:09 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
Hi Ben
>
> Quoth "Dave Saville" <dave@invalid.invalid>:
> > On Sat, 23 Feb 2013 09:49:38 UTC, "Dave Saville"
> > <dave@invalid.invalid> wrote:
> >
> > > I have a perl script that cleans up temporary directories at boot. If
> > > a file in one of those directories is read only I get a "permission
> > > denied" message from unlink. Note this is not a *nix or Windows
> > > system.
>
> What sort of system is it?
OS/2
>
> > > If OTOH I cd to said directory and issue "rm -f *" they go
> > > without a murmur.
> > >
> > > Can unlink be made to behave like "rm -f" or do I have to use the
> > > command in backticks?
Thanks for the tip to use system rather than backticks. But I don't
think permissions has anything to do with it. For instance:
[T:\tmp\openjdk6_b27_jre_os2_ga5-20130217]ls -l
total 192
-rw-rw-rw- 1 root 0 1530 Feb 17 02:30 ASSEMBLY_EXCEPTION
drwxrwxrwx 1 root 0 0 Feb 23 12:11 bin
-rw-rw-rw- 1 root 0 7526 Feb 17 00:18 CHANGES.OS2
drwxrwxrwx 1 root 0 0 Feb 23 12:11 lib
-rw-rw-rw- 1 root 0 19610 Feb 17 02:30 LICENSE
-rw-rw-rw- 1 root 0 13299 Feb 17 00:41 README.OS2
-rw-rw-rw- 1 root 0 129126 Feb 17 02:30 THIRD_PARTY_README
I run my script and afterwards:
[T:\]ls -lR /tmp/openjdk6_b27_jre_os2_ga5-20130217/
/tmp/openjdk6_b27_jre_os2_ga5-20130217/:
total 32
-rw-rw-rw- 1 root 0 1530 Feb 17 02:30 ASSEMBLY_EXCEPTION
drwxrwxrwx 1 root 0 0 Feb 23 10:39 lib
-rw-rw-rw- 1 root 0 19610 Feb 17 02:30 LICENSE
The script threw permission denied on those two files and some in lib
which is why lib is still there of course - not empty.
Upon reflection I guess it must be an OS thing - I really just posted
here in case there was an option to unlink I did not know about.
--
Regards
Dave Saville
------------------------------
Date: 23 Feb 2013 17:47:11 GMT
From: greymaus <maus@mail.com>
Subject: Re: Unlink help
Message-Id: <slrnkihdgg.8cv.maus@gmaus.org>
On 2013-02-23, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth "Dave Saville" <dave@invalid.invalid>:
>> On Sat, 23 Feb 2013 09:49:38 UTC, "Dave Saville"
>> <dave@invalid.invalid> wrote:
>>
>> > I have a perl script that cleans up temporary directories at boot. If
>> > a file in one of those directories is read only I get a "permission
>> > denied" message from unlink. Note this is not a *nix or Windows
>> > system.
>
> What sort of system is it?
My own thought, as most/all ssystems now are *unix or windows.
>
>> > If OTOH I cd to said directory and issue "rm -f *" they go
>> > without a murmur.
>> >
>> > Can unlink be made to behave like "rm -f" or do I have to use the
>> > command in backticks?
>
> Unlink alone cannot be made to do anything other than call unlink(2) (or
> your local equivalent). If your system uses Unix-like permissions, or if
> perl emulates them sufficiently, you can change the relevant permissions
> with chmod before trying the unlink. You can also use
> File::Path::rmtree, which will do this for you.
>
> If you do decide to run rm(1), do it with system rather than backticks.
>
>> My mistake - it is not files that are read only. I can see no
>> difference between files it will delete and those it won't It usually
>> happens when it is trying to delete an unloaded tarball - some of the
>> files give "permission denied".
>
> Under Unix you need write permission to a directory to delete files in
> it. If that's not the case on your system you will need to find out what
> is making the difference.
>
> Ben
>
--
maus
.
.
...
------------------------------
Date: Sat, 23 Feb 2013 19:20:18 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Unlink help
Message-Id: <ichnv9-44c.ln1@anubis.morrow.me.uk>
Quoth greymaus <maus@mail.com>:
> On 2013-02-23, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth "Dave Saville" <dave@invalid.invalid>:
> >> On Sat, 23 Feb 2013 09:49:38 UTC, "Dave Saville"
> >> <dave@invalid.invalid> wrote:
> >>
> >> > I have a perl script that cleans up temporary directories at boot. If
> >> > a file in one of those directories is read only I get a "permission
> >> > denied" message from unlink. Note this is not a *nix or Windows
> >> > system.
> >
> > What sort of system is it?
>
> My own thought, as most/all ssystems now are *unix or windows.
That's not at all true. Of the systems that perl currently runs on, VMS,
OS/2, NetWare, and Stratus VOS are definitely neither Unix nor Win32,
and Cygwin, Haiku (BeOS) and QNX are a bit marginal. Other systems perl
has run on in the past are RISC OS, Mac OS Classic, DOS, Amiga OS,
Symbian, OS/390, OS/400, BS2000, and Plan 9, though I don't think any of
those ports are currently functional.
Ben
------------------------------
Date: Sat, 23 Feb 2013 22:29:30 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Unlink help
Message-Id: <slrnkiid5q.sl3.hjp-usenet3@hrunkner.hjp.at>
On 2013-02-23 12:31, Dave Saville <dave@invalid.invalid> wrote:
> On Sat, 23 Feb 2013 11:57:09 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
>> Quoth "Dave Saville" <dave@invalid.invalid>:
>> > On Sat, 23 Feb 2013 09:49:38 UTC, "Dave Saville"
>> > <dave@invalid.invalid> wrote:
>> > > I have a perl script that cleans up temporary directories at boot. If
>> > > a file in one of those directories is read only I get a "permission
>> > > denied" message from unlink. Note this is not a *nix or Windows
>> > > system.
>>
>> What sort of system is it?
>
> OS/2
[...]
> [T:\tmp\openjdk6_b27_jre_os2_ga5-20130217]ls -l
> total 192
> -rw-rw-rw- 1 root 0 1530 Feb 17 02:30 ASSEMBLY_EXCEPTION
Does OS/2 come with an "ls" command or is this a from a third party? If
it's not a native command then I would assume that it doesn't display
the real permissions as implementend by the OS, but some unix-like
approximation.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sun, 24 Feb 2013 11:31:48 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Unlink help
Message-Id: <fV45K0OBJxbE-pn2-vnznRh9hoBLO@paddington.bear.den>
On Sat, 23 Feb 2013 21:29:30 UTC, "Peter J. Holzer"
<hjp-usenet3@hjp.at> wrote:
> On 2013-02-23 12:31, Dave Saville <dave@invalid.invalid> wrote:
> > On Sat, 23 Feb 2013 11:57:09 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
> >> Quoth "Dave Saville" <dave@invalid.invalid>:
> >> > On Sat, 23 Feb 2013 09:49:38 UTC, "Dave Saville"
> >> > <dave@invalid.invalid> wrote:
> >> > > I have a perl script that cleans up temporary directories at boot. If
> >> > > a file in one of those directories is read only I get a "permission
> >> > > denied" message from unlink. Note this is not a *nix or Windows
> >> > > system.
> >>
> >> What sort of system is it?
> >
> > OS/2
> [...]
> > [T:\tmp\openjdk6_b27_jre_os2_ga5-20130217]ls -l
> > total 192
> > -rw-rw-rw- 1 root 0 1530 Feb 17 02:30 ASSEMBLY_EXCEPTION
>
> Does OS/2 come with an "ls" command or is this a from a third party? If
> it's not a native command then I would assume that it doesn't display
> the real permissions as implementend by the OS, but some unix-like
> approximation.
No it's a port. What I have discovered is that it stores the *nix
perms in the file's Extended Attributes. If there are none then it
displays -rw-rw-rw for files and drwxrwxrwx for directories. It knows
nothing about DOSish attributes of Archive, System, Hidden & Read
only. However, if one uses the, also ported, chmod then the EA's are
changed for persistance *and* if the bit in question is "Read only" it
also updates the OS attribute. Unfortunately it does not work the
other way around. ie if one uses attrib +R foo it does not see it.
This particular problem was un-archiving a zip with some files read
only. The OS attribute was set but not the EA's.
--
Regards
Dave Saville
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3886
***************************************
